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

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

[Robert P. J. Day]

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

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

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

[Robert P. J. Day]

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

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

[Jan Engelhardt]

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

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

[Robert P. J. Day]

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

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

[Jan Engelhardt]

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

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

[Robert P. J. Day]

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

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

[Carlo Florendo]

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

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

[DervishD]

    Hi Carlo :)

 * Carlo Florendo <subscribermail@gmail.com> 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!

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

[Robert P. J. Day]

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

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

[Stefan Richter]

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/