Messages in this thread | | | Date | Wed, 11 Apr 2007 03:58:36 -0400 (EDT) | From | "Robert P. J. Day" <> | Subject | "menu" versus "menuconfig" -- they're *both* a bad idea |
| |
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/
| |