lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.64.0704110509200.11343@CPE00045a9c397f-CM001225dbafb6>
Date:	Wed, 11 Apr 2007 05:25:53 -0400 (EDT)
From:	"Robert P. J. Day" <rpjday@...dspring.com>
To:	Jan Engelhardt <jengelh@...ux01.gwdg.de>
cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: 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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ