From: "Robert P. J. Day" <rpjday@mindspring.com>
To: Linux kernel mailing list <linux-kernel@vger.kernel.org>
Subject: making entire driver submenus selectable
Date: Sat, 25 Nov 2006 07:17:46 -0500 (EST) [thread overview]
Message-ID: <Pine.LNX.4.64.0611250700480.21208@localhost.localdomain> (raw)
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2038 bytes --]
part 1:
by way of intro, note how under "General setup", the last entry:
[ ] Configure standard kernel features (for small systems) --->
visually represents a sub-menu and *ostensibly* shows whether any of
those sub-menu choices will be selectable based on that top-level
selection.
why can't this be applied more often, particularly under the
"Device Drivers" menu? there are numerous categories under that menu
where you have to *go* to that submenu just to see that that option
has been deselected in its entirety. why not use the same technique
as above and make those driver submenus selectable?
as an example, i've attached a trivial patch that does this for MTD
support. personally, i'd love to see a Drivers menu in which i could
*immediately* see which sub-categories are entirely deselected without
having to go into each one one at a time, and the kind of patch i've
attached for MTD would seem to allow just that. (other submenus where
this would make sense would be things like Fusion MPT, ISDN, Telephony
... the list goes on and on.)
(an even better approach would be to have the "--->" submenu visual
disappear if you deselect that option, but i'm not greedy -- i'll take
what i can get. :-)
thoughts? and, yes, i can submit patches. :-)
part 2:
returning to that top-level "General setup" menu, if i see something
like this:
[ ] Configure standard kernel features (for small systems) --->
and i don't know any better, i would have assumed that deselecting
that top-level entry would subsequently deselect all sub-menu entries.
but that's not what happens.
even without selecting that top-level config option, one of the
sub-menu entries:
[*] Include all symbols in kallsyms
is still selected. in fact, that option doesn't even depend on the
sub-menu that it's a part of. i think that's extremely misleading --
i think that menu entries should all explicitly depend on the sub-menu
that they're a part of, to avoid potential confusion.
thoughts on that too?
rday
[-- Attachment #2: Type: TEXT/PLAIN, Size: 578 bytes --]
diff --git a/drivers/mtd/Kconfig b/drivers/mtd/Kconfig
index a304b34..a0c9f13 100644
--- a/drivers/mtd/Kconfig
+++ b/drivers/mtd/Kconfig
@@ -1,8 +1,6 @@
# $Id: Kconfig,v 1.11 2005/11/07 11:14:19 gleixner Exp $
-menu "Memory Technology Devices (MTD)"
-
-config MTD
+menuconfig MTD
tristate "Memory Technology Device (MTD) support"
help
Memory Technology Devices are flash, RAM and similar chips, often
@@ -280,6 +278,3 @@ source "drivers/mtd/devices/Kconfig"
source "drivers/mtd/nand/Kconfig"
source "drivers/mtd/onenand/Kconfig"
-
-endmenu
-
reply other threads:[~2006-11-25 12:21 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.LNX.4.64.0611250700480.21208@localhost.localdomain \
--to=rpjday@mindspring.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®