* Russell King <rmk+lkml@arm.linux.org.uk> wrote:

quoted text
> On Mon, Feb 05, 2007 at 04:56:27PM +0100, Ingo Molnar wrote:
> > btw., this whole select problem is not limited to Aunt Tillie: in a 
> > couple of cases in the past few months when i saw some weird code in a 
> > driver and tried to enable it i had to search around for many minutes 
> > and enable random options to figure out its config dependencies until i 
> > had the driver truly enabled. (if there's some easy solution to this 
> > then i'm all ears - but i exclude the easiest solution of adding me to 
> > the 'aunt' category ;-) I think that by blaming Aunt Tillie you might be 
> > missing the real problem.
> 
> Adding a 'select' statement might solve that particular problem:
> 
>  "What config symbols do I need to turn on to enable FOO"
> 
> but it creates another problem which is at precisely the same level. 
> IOW:
> 
>  "What config symbols do I need to turn off to disable FOO"
> 
> Both require the use of grep to solve it.  Both are as bad as each 
> other.  'select' only moves the problem - it doesn't actually solve 
> anything.

yes, in the example above i only outlined that the problem is real and 
not limited to Aunt Tillie's.

quoted text
> The real problem is that "band-aiding" the problem is all too easy, so 
> we just bung a select in.  We're actually storing up bigger problems 
> for the future, making the kernel configuration system more and more 
> complex, sometimes creating circular dependencies through 
> select/depends, basically turning it into something several orders of 
> magnitude worse than the original shell scripts.

circular dependencies are nicely detected, warned about and worked 
around by the Kconfig system. I fixed one such bug recently. I have to 
say the Kconfig code has improved very significantly during the past few 
years and i dont want any of what i'm writing to be understood as a 
criticism. It's more in the direction of: 'ok, things are pretty nice 
and the config tree works currently, now lets make it even cleaner'.

quoted text
> The only real way I see the problem truely getting solved is if folk 
> start standing up against throwing "select" in so there's some 
> motivation to actually fix the underlying problem.

the solution is i think two-fold and goes along the lines i outlined in 
the previous mail:

 - make dependencies as tree-alike as possible

note that the MTD problem was caused by those drivers not being part of 
a clean tree.

But even with a 100% clean tree structure there's a legitimate desire to 
select modules several layers down from the current 'leaf' nodes of the 
config tree:

 - provide a tool mode (not a Kconfig language feature) to navigate the
   complete tree of features (including currently disabled ones) and
   enable the selection of components (by automatically selecting all
   dependent features).

	Ingo
-
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/