From: Stephen Wille Padnos <stephen.willepadnos@verizon.net>
To: "Robert P. J. Day" <rpjday@mindspring.com>
Cc: Linux kernel mailing list <linux-kernel@vger.kernel.org>
Subject: Re: a really annoying feature of the config menu structure
Date: Tue, 18 Feb 2003 20:24:54 -0500 [thread overview]
Message-ID: <3E52DCE6.5090403@verizon.net> (raw)
In-Reply-To: <Pine.LNX.4.44.0302181955260.24383-100000@dell>
Robert P. J. Day wrote:
>On Tue, 18 Feb 2003, Stephen Wille Padnos wrote:
>
>
>
>>[snip]
>>
>>
>>
>>> as i see it, this can only get worse. the current
>>>erratic and disorganized structure of the config menus
>>>is proof of that.
>>>
>>> comments?
>>>
>>>
>>>
>>I think the problem with the "Multimedia" menu is that it's misnamed.
>>It should actually be the "tuners" menu - it's there for audio, digital
>>video, and video tuners. The same could be said of the networking menu,
>>and presumably others.
>>
>>You can actually reorganize things simply by changing the structure of
>>the top-level Kconfig file. With the following patches, I reorganized
>>the multimedia options into the form that you are probably looking for.
>>(hopefully they won't be mangled by my mailer)
>>
>>With not too much rewriting (many small changes, I think), the menus can
>>be organized much better.
>>
>>Essentially, each subdirectory has a Kconfig file that does _not_
>>declare itself a standalone menu. This allows a parent to decide
>>whether or not to include it in another menu. The menu should only have
>>options that pertain to things in its' directory. ie, the Kconfig file
>>in drivers/net should not include "Networking" as an option - that is a
>>higher level decision (ie, it decides whether or not to include the
>>drivers/net config file).
>>
>>Then, the Kconfig files from various subdirectories can be ordered in
>>whatever way makes sense from a user's point of view
>>
>>--- drivers/media/Kconfig.orig 2003-02-18 17:15:46.000000000 -0500
>>+++ drivers/media/Kconfig.new 2003-02-18 17:25:27.000000000 -0500
>>@@ -2,8 +2,6 @@
>> # Multimedia device configuration
>> #
>>
>>-menu "Multimedia devices"
>>-
>> config VIDEO_DEV
>> tristate "Video For Linux"
>> ---help---
>>@@ -32,5 +30,4 @@
>>
>> source "drivers/media/dvb/Kconfig"
>>
>>-endmenu
>>
>>
>
>... some patch snipped here ...
>
> oh, i'm aware that (for example) the multimedia menu stuff
>can be fixed if you go into the directory and change the Kconfig
>file. but that's exactly the kind of thing i'm trying to
>*avoid*. philosophically, it would be ideal to let each
>directory be a self-contained bundle of related modules
>and the Kconfig menu file that goes with them.
>
> what has to be avoided is for any of these directories to
>give itself a menu label that implies that it's fairly high
>up in the food chain, and subsequently leave no way to
>incorporate submenus beneath it. (see, eg., "Multimedia")
>
The only change to "drivers/media/Kconfig" was the removal of the menu
and endmenu lines, for exactly the purpose of removing the title.
> rearranging the top-level options by having to make changes
>to any of the individual subdirectory Kconfig files is just not
>an appealing option.
>
Since the individual files aren't "relocatable" at this point, I think
that at least *one* change might be needed :) The idea would be to
change it once, and not need to do so again for layout changes.
> i realize that all of this sounds like much ado about
>nothing, but as more options are added to the kernel, this
>is just going to get more unmanageable, but i have no idea
>if anyone else thinks this is something worth addressing.
>
> if not, i'm willing to drop it.
>
>rday
>
I think it's worth pursuing - I've had no end of annoyance with USB and
ieee1394 configuration (among other things).
- Steve
next prev parent reply other threads:[~2003-02-19 1:14 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-02-18 21:28 a really annoying feature of the config menu structure Robert P. J. Day
2003-02-18 22:33 ` Stephen Wille Padnos
2003-02-19 1:04 ` Robert P. J. Day
2003-02-19 1:24 ` Stephen Wille Padnos [this message]
2003-02-19 2:09 ` Robert P. J. Day
2003-02-19 1:56 ` Alan Cox
2003-02-19 1:31 ` Stephen Wille Padnos
2003-02-19 3:03 ` Alan Cox
2003-02-19 2:13 ` Robert P. J. Day
2003-02-19 9:49 ` Tomas Szepe
2003-02-19 13:19 ` Helge Hafting
2003-02-19 13:31 ` Robert P. J. Day
2003-02-19 14:35 ` John Bradford
2003-02-19 13:33 ` Robert P. J. Day
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=3E52DCE6.5090403@verizon.net \
--to=stephen.willepadnos@verizon.net \
--cc=linux-kernel@vger.kernel.org \
--cc=rpjday@mindspring.com \
/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