Re: [RFC] top-level config menu dependencies

[Tomas Szepe <szepe@pinerecords.com>]

> [zippel@linux-m68k.org]
> 
> > While converting the way submenus appear in menuconfig depending on
> > their main, parent config option, I stumbled upon certain subsystems
> > (such as MTD or IrDA) that should clearly have an on/off switch directly
> > in the main menu so that one doesn't have to enter the corresponding
> > submenus to even see if they're enabled or disabled.
> > 
> > Since the new kernel configurator would have no problems with such
> > a setup, I'm posting this RFC to get the general opinion on whether
> > this should be carried on with.  I'm willing to create and send in
> > the patches.
> 
> While all config programs should be able to handle this, it might look a
> bit strange. Especially the split view of xconfig relies a bit on the
> current organisation of the config data.
> My idea to handle this would be to turn e.g.:
> 
> menu "Memory Technology Devices (MTD)"
> 
> config MTD
> 	tristate "Memory Technology Device (MTD) support"
> 
> into something like this:
> 
> menuconfig MTD
> 	tristate "Memory Technology Device (MTD) support"
> 
> This would give the front ends the most flexibility. The required
> changes are quite small, so it should be doable for 2.6. I'm not
> completely sure about the syntax yet, but above is the most likely
> version.

If I understand you correctly, what you are proposing is equivalent
to how the following currently works:

config MTD
	tristate "Memory Technology Device (MTD) support"

menu "Memory Technology Device (MTD) support"
	depends on MTD

...

endmenu

It seems to me the infrastructure you've provided by kconfig
is completely sufficient -- it's the config frontends that would
require minor updates (xconfig mainly, menuconfig seems to be
working nicely -- at least with the setup I outlined above).

-- 
Tomas Szepe <szepe@pinerecords.com>