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

["Robert P. J. Day" <rpjday@mindspring.com>]

  i can still remember the days when *i* was pushing for the idea of
using "menuconfig" instead of "menu" more in the config menus, but
i've finally realized they're *both* badly designed for what jan is
trying to do here.

  the best example of why "menuconfig" is a mess is in the menu entry
for:

  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.  that's simply wrong.
it's hideously non-intuitive to explicitly not select a top-level
choice, only to learn that there still exist selectable sub-choices.

  and the Kconfig structure defining that is also overly messy:

===========================
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.

  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.

rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================
-
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/