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.61.0704111059190.32056@yvahk01.tjqt.qr>
Date:	Wed, 11 Apr 2007 11:06:26 +0200 (MEST)
From:	Jan Engelhardt <jengelh@...ux01.gwdg.de>
To:	"Robert P. J. Day" <rpjday@...dspring.com>
cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: 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 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