Re: "menu" versus "menuconfig" -- they're *both* a bad idea

[Jan Engelhardt]

On Apr 11 2007 03:58, Robert P. J. Day wrote:
>
>  General setup
>    [ ] Configure standard kernel features (for small systems)  --->
>
>note how, even if you don't choose to configure features for small
>systems, if you go under that menu entry, you're still presented with
>a couple config options related to kallsyms.

A CONFIG_EMBEDDED bug. This should perhaps be changed.
Or at best, deactivate the ---> part when it's N.

>===========================
>menuconfig EMBEDDED
>	bool "Configure standard kernel features (for small systems)"
>	...
>===========================
>
>  first, for submenu entries to show up if you select features for
>"small systems," you need to tack "if EMBEDDED" onto every prompt,
>
>...
>bool "Sysctl syscall support" if EMBEDDED
>bool "Load all symbols for debugging/ksymoops" if EMBEDDED
>bool "Support for hot-pluggable devices" if EMBEDDED
>...
>
>and so on, which gets annoyingly repetitive after a while.

Can we agree that CONFIG_EMBEDDED is a specialcase?

>
>  worse, you have options that don't even depend on the menu that
>they're a sub-entry for, as in:
>
>...
>config KALLSYMS_ALL
>        bool "Include all symbols in kallsyms"
>        depends on DEBUG_KERNEL && KALLSYMS
>...
>
>  what is really needed here is a new Kconfig structure, perhaps
>called "selectablemenuconfig" (or something not quite so verbose),
>which would, in one fell swoop:
>
>1) be singly-clickable to activate or de-activate an entire submenu
>and possibly further submenus, and
>
>2) make all of those submenu entries *automatically* depend on the
>config option that represents the submenu.
>
>  at the moment, you can do pretty much the same thing with
>"menuconfig" but it's downright messy.  rather than make all these
>"menuconfig" changes right now, i would prefer to see a cleaner
>structure introduced that does most of that work under the hood.


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