i finally decided to get serious and start looking at the
overall config menu structure, to re-arrange the menus and
submenus so that it made more sense and flowed more logically,
and i ran into a really annoying feature that makes it
virtually impossible to do this. (this is all based on the
assumption that i haven't overlooked something obvious.)
so what's the problem?
my plan was to start collecting some of the logically-related
menu entries together, and to have a main menu top-level entry,
and some submenus for more specific related sub-items. some
of you may remember that i proposed something like this for
the filesystems menu.
other areas where this would have made sense would be for
something like a "Networking" main menu, with submenus for
things like ISDN, Wireless and so on, those all being
subsets of networking. it *sounded* like a good idea, but
the way the menus are laid out, this is going to be difficult.
the main menu file appears to be .../arch/i386/Kconfig,
which defines some menus and "source"s others, and therein
lies the problem. it's perfectly reasonable to source a
Kconfig file from a kernel subdirectory if that file
represents a submenu -- such a file can be sourced in the
*middle* of a top-level menu definition, and will therefore
appear as a submenu in the config screen.
however, those sourced files are, for the most part,
complete menu definitions on their own, so they *cannot*
have further submenus placed inside them, and this is
a pain when any of those are used directly in the top level
in the main Kconfig file.
a perfect example is the menu for "Networking support".
this is obtained simply with
source "net/Kconfig"
but since that file was (presumably) created by the person
who was looking after the networking code in that directory,
there is no way to source that file and simultaneously give
it some appropriate submenus, like ISDN, Wireless and so on.
this is going to be the case with *every* autonomous
directory that comes with its own Kconfig file -- it will
never give the top-level Kconfig file the flexibility
to assign it any submenus, and this is pretty annoying
with something as generic as "Networking support".
the only possible solution to make this work is to
make sure each directory with its own Kconfig file never
assumes it's going to be a top-level menu -- it has to
assume it might be incorporated as a submenu.
another consequence is that it's a bad idea to have
top level menu entries *both* have config options *and*
submenus, as is done with "Power management" and "ACPI"
(and Filesystems for that matter). a better solution is
for each kernel source directory to create and manage its
own Kconfig file and define its own menu, then design the
top-level file to act simply as a wrapper around all of these.
another good example is "Multimedia", which would normally
include "Sound" configuration, wouldn't you think? but as it
stands, this is currently impossible -- the Multimedia
menu is simply sourced from its directory, and there is no
way to assign it any submenus, like Sound, Video and others
that really belong there.
as i see it, this can only get worse. the current
erratic and disorganized structure of the config menus
is proof of that.
comments?
rday
[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
--- arch/i386/Kconfig.orig 2003-02-18 17:17:49.000000000 -0500
+++ arch/i386/Kconfig 2003-02-18 17:18:32.000000000 -0500
@@ -1529,14 +1529,13 @@
source "drivers/char/Kconfig"
-#source drivers/misc/Config.in
-source "drivers/media/Kconfig"
-
source "fs/Kconfig"
source "drivers/video/Kconfig"
-menu "Sound"
+#source drivers/misc/Config.in
+menu "MultiMedia (tuners, sound, video"
+source "drivers/media/Kconfig"
config SOUND
tristate "Sound card support"
On Tue, 2003-02-18 at 22:33, 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.
It covers lots of tunerless mpeg and mjpeg stuff. Eg the DVB stuff will
eventually include the Margi PCMCIA DVD player and we already have other
pure mpeg or pure webcam stuff in there
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")
rearranging the top-level options by having to make changes
to any of the individual subdirectory Kconfig files is just not
an appealing option.
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
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
Alan Cox wrote:
>On Tue, 2003-02-18 at 22:33, 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.
>>
>>
>
>It covers lots of tunerless mpeg and mjpeg stuff. Eg the DVB stuff will
>eventually include the Margi PCMCIA DVD player and we already have other
>pure mpeg or pure webcam stuff in there
>
It seems that the mjpeg stuff will be in the wrong place when it starts
being used by non-DVB modules. I see the two (DVB and mjpeg) as
distinct entities - like ethernet drivers and ipv4. (DVB drivers should
let you change channels and whatnot, mjpeg drivers should allow you to
decode data streams from any available source.)
- Steve
On Wed, 2003-02-19 at 01:31, Stephen Wille Padnos wrote:
> It seems that the mjpeg stuff will be in the wrong place when it starts
> being used by non-DVB modules. I see the two (DVB and mjpeg) as
> distinct entities - like ethernet drivers and ipv4. (DVB drivers should
> let you change channels and whatnot, mjpeg drivers should allow you to
> decode data streams from any available source.)
Its more by API than by hardware. One driver sometimes covers cards with
and without tuners, with and without mpeg hardware and so on. Classification
is nice, but like biology its never neat
On Tue, 18 Feb 2003, Stephen Wille Padnos wrote:
> Robert P. J. Day wrote:
> > 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.
that's still not good enough. think about it this way: every
directory with related source that makes up a subcomponent of the
kernel -- I2C, USB, kernel hacking, whatever -- should theoretically
be under the control of a maintainer.
that maintainer should not only look after patches to the
code, but should keep the Kconfig file in that directory up
to date. ideally, that maintainer should be the ultimate
authority for *everything* that happens in that directory.
at the top level, whoever organizes the main config menu
should not have to do any more than source other Kconfig
files to pull them into the top-level menu. this gives the
main config person total freedom to shift around menu entries
and submenus without *ever* going into one of those lower
directories and making *any* changes to their contents.
from my perspective, it's not good enough that you only
had to remove the two menu definition lines -- you shouldn't
have had to do *anything* in what you can consider someone
else's directory. now, assuming that you appreciate that,
yes, this is a problem, what are the possible solutions?
i can think of a couple solutions, but they require making
sure everyone agrees on some kind of standard for how maintainers
are going to manage their Kconfig files so that they're
movable at will.
i'll hold off going any further until i'm sure i'm making
sense here.
rday
On 19 Feb 2003, Alan Cox wrote:
> On Wed, 2003-02-19 at 01:31, Stephen Wille Padnos wrote:
> > It seems that the mjpeg stuff will be in the wrong place when it starts
> > being used by non-DVB modules. I see the two (DVB and mjpeg) as
> > distinct entities - like ethernet drivers and ipv4. (DVB drivers should
> > let you change channels and whatnot, mjpeg drivers should allow you to
> > decode data streams from any available source.)
>
> Its more by API than by hardware. One driver sometimes covers cards with
> and without tuners, with and without mpeg hardware and so on. Classification
> is nice, but like biology its never neat
true enough -- there's no perfect solution, but i'm convinced that
it can certainly be much more intuitive and organized that it is now.
i think that, as it stands now, the kernel configuration process is
the inevitable result of the linux kernel growing so fast and having
so many new features added to it that there simply was never the
time to step back, take a deep breath and clean up what was already
there before marching on.
rday
> [[email protected]]
>
> > > It seems that the mjpeg stuff will be in the wrong place when it starts
> > > being used by non-DVB modules. I see the two (DVB and mjpeg) as
> > > distinct entities - like ethernet drivers and ipv4. (DVB drivers should
> > > let you change channels and whatnot, mjpeg drivers should allow you to
> > > decode data streams from any available source.)
> >
> > Its more by API than by hardware. One driver sometimes covers cards with
> > and without tuners, with and without mpeg hardware and so on. Classification
> > is nice, but like biology its never neat
>
> true enough -- there's no perfect solution, but i'm convinced that
> it can certainly be much more intuitive and organized that it is now.
Please wait until Roman Zippel pushes the "menuconfig" grammar extension.
--
Tomas Szepe <[email protected]>
Robert P. J. Day wrote:
> i finally decided to get serious and start looking at the
> overall config menu structure, to re-arrange the menus and
> submenus so that it made more sense and flowed more logically,
[...]
> other areas where this would have made sense would be for
> something like a "Networking" main menu, with submenus for
> things like ISDN, Wireless and so on, those all being
> subsets of networking.
It isn't that simple. ISDN is more than networking, and even
useable without it. Non-network uses of isdn:
* Making an answering machine or voicemail from a pc
and one or more isdn cards.
* Use isdn for dialing into non-IP services like a BBS.
So you have a choice between sticking all networking
things in a network menu (and have stuff like ISDN
spread out in different places (network and other ISDN at least)
or put all ISDN in one plave and have network etc. spread over
various networking technologies like today.
There is no config layout that is "clean" for everybody,
because it is fundamentally trying to stuff a generic graph
into a hierarchical tree.
Helge Hafting
On Wed, 19 Feb 2003, Helge Hafting wrote:
> Robert P. J. Day wrote:
> > i finally decided to get serious and start looking at the
> > overall config menu structure, to re-arrange the menus and
> > submenus so that it made more sense and flowed more logically,
> [...]
> > other areas where this would have made sense would be for
> > something like a "Networking" main menu, with submenus for
> > things like ISDN, Wireless and so on, those all being
> > subsets of networking.
>
> It isn't that simple. ISDN is more than networking, and even
> useable without it. Non-network uses of isdn:
>
> * Making an answering machine or voicemail from a pc
> and one or more isdn cards.
> * Use isdn for dialing into non-IP services like a BBS.
>
> So you have a choice between sticking all networking
> things in a network menu (and have stuff like ISDN
> spread out in different places (network and other ISDN at least)
>
> or put all ISDN in one plave and have network etc. spread over
> various networking technologies like today.
>
> There is no config layout that is "clean" for everybody,
> because it is fundamentally trying to stuff a generic graph
> into a hierarchical tree.
ok, so i could have picked a better example than ISDN as a
submenu for "Networking", but my main point still stands --
the "Networking support" menu cannot have submenus incorporated
below it without changing the specific Kconfig file for that
directory. and that gets incredibly messy as one tries to
follow a menu structure around the various kernel source
directories. ("Multimedia" was another example of an
unfortunately inflexible menu, so you see my point.)
perhaps you're right -- perhaps there is no nice solution
and there's not much point pursuing this. but given that
linux is being more widely adopted every day, it's clear
that more and more people are going to be building kernels,
it still might be worth trying to address this before it
goes much further.
i'll go with tomas' suggestion to wait until the new
config grammar is out. until then, i'm just going to
play with theoretically reorganizing the menus and see
what eventually makes sense to me, regardless of whether
it's ever implemented or not.
rday
On Wed, 19 Feb 2003, Helge Hafting wrote:
> There is no config layout that is "clean" for everybody,
> because it is fundamentally trying to stuff a generic graph
> into a hierarchical tree.
and, just to be clear, i never suggested that there is
a single, perfect solution that would make everyone happy.
i *do* contend that the current layout could be improved
immensely, that's all.
the only question is whether it's feasible or worth doing.
rday
> but given that linux is being more widely adopted every day, it's
> clear that more and more people are going to be building kernels
Not really - the vast majority of Linux users don't recompile the
kernel themselves, but simply use the one their distribution
provides.
John.