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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
