Re: "menu" versus "menuconfig" -- they're *both* a bad idea
Robert P. J. Day wrote: > but it should be obvious that, if you look at the Kconfig files, each > and every "select" directive has the potential to override a decision > you think you might have made elsewhere. In other words, the author of a Kconfig file should not assume he knows best how users want to configure kernels. IMO Kconfig files should be nothing more than a list of the existing options with statements how they depend on each other, plus the inline help texts, plus one default logical grouping (e.g. Drivers -> SCSI -> most of the SCSI drivers). All the rest, i.e. supporting users to get to the desired configuration, should be left to the various UIs to Kconfig --- including the bidirectional tracking of dependencies, presentation in different logical groups than the default one, etc. However, the trend here seems to be to turn Kconfig into a _program_ (a script rather than a description), and to tune that program to the needs of a subgroup of Kconfig endusers. > I'm just sayin'. Me 2. -- Stefan Richter -=-=-=== -=-- -==-- http://arcgraph.de/sr/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: "menu" versus "menuconfig" -- they're *both* a bad idea
On Thu, 12 Apr 2007, Carlo Florendo wrote: > Robert P. J. Day wrote: > > (in short, if i, the builder, explicitly choose *not* to add a > > certain feature to my build, i think i have every right to expect that > > some other part of my configuration isn't quietly going to put some > > sub-choice of that feature back in behind my back.) > > I agree with this. However, if another feature actually depends on > another explicitly unselected feature, there should at least be a > warning prompt that such is the case. > > It probably would be hard though to track all dependencies. i can't imagine this is a widespread problem in the tree -- i mean, we keep using CONFIG_EMBEDDED as an example, and we mostly agree that that's just a bad design, anyway. but it should be obvious that, if you look at the Kconfig files, each and every "select" directive has the potential to override a decision you think you might have made elsewhere. I'm just sayin'. 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: "menu" versus "menuconfig" -- they're *both* a bad idea
Hi Carlo :) * Carlo Florendo <[EMAIL PROTECTED]> dixit: > Robert P. J. Day wrote: > > (in short, if i, the builder, explicitly choose *not* to add a > >certain feature to my build, i think i have every right to expect that > >some other part of my configuration isn't quietly going to put some > >sub-choice of that feature back in behind my back.) > > I agree with this. However, if another feature actually depends on another > explicitly unselected feature, there should at least be a warning prompt > that such is the case. > > It probably would be hard though to track all dependencies. I think that it wouldn't be that hard: some cases (like CONFIG_EMBEDDED) are easy to spot, and the harder ones are going to bite someone's arse sooner or later. If a bad dependency tracking doesn't cause any harm, it doesn't need to be fixed right now, and if it bites, it can be fixed before the next -stable release sees the light. Fortunately, all dependencies (at least all that can cause harm if untracked) will be spotted before the next minor kernel release. Hopefully... Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: "menu" versus "menuconfig" -- they're *both* a bad idea
Robert P. J. Day wrote: (in short, if i, the builder, explicitly choose *not* to add a certain feature to my build, i think i have every right to expect that some other part of my configuration isn't quietly going to put some sub-choice of that feature back in behind my back.) I agree with this. However, if another feature actually depends on another explicitly unselected feature, there should at least be a warning prompt that such is the case. It probably would be hard though to track all dependencies. Best Regards, Carlo -- Carlo Florendo Softare Engineer/Network Co-Administrator Astra Philippines Inc. UP-Ayala Technopark, Diliman 1101, Quezon City Philippines http://www.astra.ph -- The Astra Group of Companies 5-3-11 Sekido, Tama City Tokyo 206-0011, Japan http://www.astra.co.jp - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: "menu" versus "menuconfig" -- they're *both* a bad idea
On Wed, 11 Apr 2007, Jan Engelhardt wrote: > > On Apr 11 2007 05:47, Robert P. J. Day wrote: > >> On Apr 11 2007 05:25, Robert P. J. Day wrote: > >> >On Wed, 11 Apr 2007, Jan Engelhardt wrote: > >> >> On Apr 11 2007 03:58, Robert P. J. Day wrote: > >> >> > >> >> A CONFIG_EMBEDDED bug. This should perhaps be changed. > >> >> Or at best, deactivate the ---> part when it's N. > >> > > >> > i'm not sure what you mean by "bug". if what you mean is that it's > >> >a bad choice of menu layout, i agree. but what's happening there > >> >is not technically "wrong" or "buggy" in the sense that it's > >> >perfectly legal based on the current design of "menuconfig". > >> > >> Of course. > > > >ok, just checking that we were actually agreeing with one another. > >:-) > > Wait, I forgot something: > > Of course, patches are welcome. :-P i'd be happy to, but the only patch i'd be thinking of would be to introduce that "dropdownmenuconfig" construct i mentioned, and i'm sort of busy packing for california so it won't happen today. :-P rday p.s. if anyone here is going to CELF 2007, i may run into you. maybe i'll wear something outrageously canadian to stand out in a crowd. :-) -- 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: "menu" versus "menuconfig" -- they're *both* a bad idea
On Apr 11 2007 05:47, Robert P. J. Day wrote: >> On Apr 11 2007 05:25, Robert P. J. Day wrote: >> >On Wed, 11 Apr 2007, Jan Engelhardt wrote: >> >> On Apr 11 2007 03:58, Robert P. J. Day wrote: >> >> >> >> A CONFIG_EMBEDDED bug. This should perhaps be changed. >> >> Or at best, deactivate the ---> part when it's N. >> > >> > i'm not sure what you mean by "bug". if what you mean is that it's >> >a bad choice of menu layout, i agree. but what's happening there >> >is not technically "wrong" or "buggy" in the sense that it's >> >perfectly legal based on the current design of "menuconfig". >> >> Of course. > >ok, just checking that we were actually agreeing with one another. >:-) Wait, I forgot something: Of course, patches are welcome. :-P Jan -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: "menu" versus "menuconfig" -- they're *both* a bad idea
On Wed, 11 Apr 2007, Jan Engelhardt wrote: > > On Apr 11 2007 05:25, Robert P. J. Day wrote: > >On Wed, 11 Apr 2007, Jan Engelhardt wrote: > >> On Apr 11 2007 03:58, Robert P. J. Day wrote: > >> > >> A CONFIG_EMBEDDED bug. This should perhaps be changed. > >> Or at best, deactivate the ---> part when it's N. > > > > i'm not sure what you mean by "bug". if what you mean is that it's > >a bad choice of menu layout, i agree. but what's happening there > >is not technically "wrong" or "buggy" in the sense that it's > >perfectly legal based on the current design of "menuconfig". > > Of course. ok, just checking that we were actually agreeing with one another. :-) 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: "menu" versus "menuconfig" -- they're *both* a bad idea
On Apr 11 2007 05:25, Robert P. J. Day wrote: >On Wed, 11 Apr 2007, Jan Engelhardt wrote: >> On Apr 11 2007 03:58, Robert P. J. Day wrote: >> >> A CONFIG_EMBEDDED bug. This should perhaps be changed. >> Or at best, deactivate the ---> part when it's N. > > i'm not sure what you mean by "bug". if what you mean is that it's >a bad choice of menu layout, i agree. but what's happening there is >not technically "wrong" or "buggy" in the sense that it's perfectly >legal based on the current design of "menuconfig". Of course. Jan -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: "menu" versus "menuconfig" -- they're *both* a bad idea
On Wed, 11 Apr 2007, Jan Engelhardt wrote: > > 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. i'm not sure what you mean by "bug". if what you mean is that it's a bad choice of menu layout, i agree. but what's happening there is not technically "wrong" or "buggy" in the sense that it's perfectly legal based on the current design of "menuconfig". even though you choose to deselect "small features," that submenu continues to display two selectable options for the simple reason that 1) they don't depend on CONFIG_EMBEDDED (clearly bad design), and 2) they're being forcibly "select"ed by other options elsewhere in the tree i think this should be avoided as much as possible, which is why i suggested a whole new menu construct such as "dropdownmenuconfig" or something equally annoying -- such a construct would *enforce* good design by not even *allowing* the silliness that is that "small features" menu. by automatically adding the appropriate dependency to every single sub-option, it would not only make the Kconfig file prettier, it would prevent what you can currently do in places like that "small features" menu -- allowing options elsewhere in the tree to explicitly override your choices. (in short, if i, the builder, explicitly choose *not* to add a certain feature to my build, i think i have every right to expect that some other part of my configuration isn't quietly going to put some sub-choice of that feature back in behind my back.) of course, there will be times where you need to something weird for which the proposed behaviour of "dropdownmenuconfig" isn't appropriate. cases like that should be viewed as *aberrations* and they can always be hacked manually if you really need to do that. but i think it would be cleaner to just introduce a new construct that Does The Right Thing 98% of the time and makes for a more intuitive design. 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: "menu" versus "menuconfig" -- they're *both* a bad idea
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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
"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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
