(if you're not interested in this ongoing discussion, there's
always the delete key. although, in all fairness, i'd be happy
to move this discussion to another forum, if people think it's
distinct enough to deserve its own list. just a thought. i'm
open to suggestions.)
in order to really demonstrate why the kernel menu layout is
really chaotic, i spent about 10 minutes going over the layout
from 2.6.0-test1-bk2, and here are some observations regarding
why it needs real work.
"General setup"
this option seems to exist only because no one took the time
to figure out where those suboptions really belonged. consider
the suboption "Support for paging of anonymous memory".
might this not go under "Processor type and features",
where there are other memory-related options?
this just seems like a grab-bag of unrelated options that
were thrown here at random.
"Power management options"
i've already whined about how you can turn off this
option and still select ACPI, which seems non-intuitive.
in addition, though, i'm not sure "CPU frequency scaling"
belongs here. it might just as well fit under "Processor type
and features", although that may be nit-picking.
"Bus options (PCI, PCMCIA, EIAS, MCA, ISA)
if this is for busses, why aren't the other busses here as
well? shouldn't USB be here as well? although, in all fairness,
USB represents such a huge collection of options, it might deserve
its own top-level entry, but even then, it would make sense to
at least have it right after the "Bus options" entry.
and what about I2C, which is described as a "slow serial bus
protocol"? it's a bus. why isn't it here?
"Generic driver options"
a single option choice deserves its own top-level menu entry?
hardly.
"Parallel port support"
this really deserves its own top-level menu entry as well?
again, hardly. why not just combine serial and parallel ports
under a single entry? "Serial and parallel ports"? regardless,
it's silly to have parallel ports way up here, and serial
drivers all the way down as a sub-menu under "Character
devices"
"Character devices" (jumping ahead just a bit)
and while we're on the subject of character devices, it's
absurd to have an entire menu structure labelled like this.
what normal people think to themselves, "hey, i want to
configure my character devices now"??
rather, they'll think, "i'll configure my mouse now. or
my floppy device. or power management". etc, etc. to lump
stuff under that menu entry just because they share that
property is really counter-productive.
as a concrete example, note the sub-menu "Mice". you've
already got some mouse configuration under "Input device support".
why not deal with mice in one place? "Character devices", indeed.
hmmmmph.
"Block devices"
same thinking here. it's not helpful to gather this many
entries under a single menu entry just because they happen to
all block devices. normal people don't think that way.
and it might (i said *might*) make more sense to keep
parallel port configuration and "Parallel port IDE device
support together", but i wouldn't defend that to the death.
it's just a thought.
"Multiple devices (RAID and LVM)"
i'm not sure this wouldn't fit just as well as a sub-menu
of "Filesystems". certainly, LVM wouldn't be out of place
there. again, just a thought.
"Fusion MPT"
hard to believe this deserves its own top-level entry,
but i could be wrong.
"IEEE 1394"
it's a bus, right? move it there.
"Networking support"
yeesh, what a mess. at the very least, if everything else
related to networking is here, ISDN should be, too. but, really,
it needs a lot more cleaning up than just that.
"Linux telephony"
might this also belong under networking?
"Input device support"
another menu in serious need of cleanup. at the very least,
if mice are dealt with here, why is there also a "Mice" entry
under "Character devices"?
"Character devices" (again)
almost all of this can be moved to other menus. "Serial
drivers" should go higher up. "I2C" qualifies as a bus.
"Mice" should be under "Input device support". you get the
idea.
"Graphics support"
it's thoroughly confusing (as many have already pointed out)
to have the "Input devices" selection control the display of the
"Console display driver support".
IMHO, "Graphics support" should involve video cards, framebuffers,
that sort of thing. not something as fundamental as virtual
consoles. i think that "Console display driver support" sub-menu
should be ripped right out of there and moved up. way up. where
no one can miss it.
"IrDA", "Bluetooth"
any reason why two wireless technologies are not next to
each other in the menu layout? perhaps as a networking
sub-option?
anyway, i could go on but i'm sure you get the idea. this
current layout could use a major overhaul.
rday
In article <[email protected]> you wrote:
> the suboption "Support for paging of anonymous memory".
> might this not go under "Processor type and features",
> where there are other memory-related options?
well, i think it is architecture independend
> "Power management options"
> in addition, though, i'm not sure "CPU frequency scaling"
> belongs here. it might just as well fit under "Processor type
> and features", although that may be nit-picking.
Power Management and System Configuration
could be a better heading
> "Bus options (PCI, PCMCIA, EIAS, MCA, ISA)
>
> if this is for busses, why aren't the other busses here as
> well? shouldn't USB be here as well?
I think this is concernd with mainboard's main bus only (i2c is an aux
mainboard bus and usb, firewire are device busses)
> "Character devices" (jumping ahead just a bit)
> "Block devices"
> "Multiple devices (RAID and LVM)"
Well, if we go along the line of using unix naming, then MD can be moved ot
block devices, not to filesystems.
> "Fusion MPT"
>
> hard to believe this deserves its own top-level entry,
> but i could be wrong.
yes, very strange.
> "IEEE 1394"
> it's a bus, right? move it there.
i would suggest to have the section separated into system internal stuff
(cpu, mainboard bus, management bus, memory, apci, ..) and external
interfaces (usb, firewire, legacy/serial/, legacy/parallel, legacy/ps2,
...)
Greetings
Bernd
--
eckes privat - http://www.eckes.org/
Project Freefire - http://www.freefire.org/
On Fri, 25 Jul 2003, Bernd Eckenfels wrote:
> In article <[email protected]> you wrote:
> > "Multiple devices (RAID and LVM)"
>
> Well, if we go along the line of using unix naming, then MD can be moved ot
> block devices, not to filesystems.
i'm still not keen on the notion of having an entire menu category
called "block devices". apart from the hard-core kernel coders here,
i don't think mere mortals think this way. but there's another concern
with any menu re-org.
from my poking around in the whole Kconfig structure, it seems that the
menu structure is tied awfully closely to the underlying directory
structure. this would make it overly difficult to shift parts of
the config menu around without dragging the corresponding directories
around as well.
so, as much as i'd like to see a more intuitive menu layout, i'm
starting to think that this may not be all that easy anymore.
it's one thing to shift menu entries around. it's quite another
to start moving entire directories around in the kernel source
tree, and it seems that that's what would be necessary. unless
i'm misreading something badly.
rday
p.s. since i'm sure there's at least a couple people here i haven't
annoyed intensely thus far :-), let me toss out two more thoughts.
checkboxes at the top level
---------------------------
some time ago, i suggested it would be nice to be able to deselect
entire submenus right at the top level. for example, it's clearly
inefficient to have to select "Parallel port support" and bring
up its corresponding submenu, if your only goal is to *deselect*
that option.
it would be really terrific to have checkboxes for deselecting
entire subsystems right at the top level, but i suspect that would
require a major rewrite of Kconfig, wouldn't it? bummer.
who defines a menu?
-------------------
the other problem i noticed is the restrictions imposed when a
Kconfig file defines its own menu title. just as one example,
consider ../drivers/acpi/Kconfig. that Kconfig file defines itself
at the very top as the menu for "ACPI Support". but who's to say
that someone else might not write another set of drivers in another
directory that relate to some other feature of ACPI?
that will be inconvenient since the Kconfig file i refer to has
already taken the inflexible position of claiming, "*i*, and only i,
shall handle ACPI, and i shall be the ACPI support menu."
frankly, i don't think Kconfig files should define their own
menu names. that should be done by their *including* files,
which gives the including files the flexibility to decide how to
name and include menus.
if this were done consistently, re-ordering the menu layout
would be a breeze. in short, if i use ACPI as an example, whoever
wrote the ACPI stuff would be responsible for writing the Kconfig
file to describe options and dependencies, but would leave the
menu name and how those menu entries were included in the overall
structure to a higher-level Kconfig file, all the way back to
the top-level Kconfig file, whose job would be to simply define
the top-level menu and include the appropriate next-level
Kconfig files.
although, i will admit, there may be limitations to this
i haven't thought of yet.
from my poking around in the whole Kconfig structure, it seems that the
menu structure is tied awfully closely to the underlying directory
structure. this would make it overly difficult to shift parts of
the config menu around without dragging the corresponding directories
around as well.
<Sources are located regarding programming hierarchy _but_
<relevant Kconfig can tune situation using 'depends' feature
<at ease so that menuconfig, kernelserver ... have an optimized view
<over kernel tree.OTOH a major problem resides in lack of functionnalities
<especially when you don't know where to look at (ie.alphabetical order,
<search engine....I'm adding those functions to kernelServer (wconf) ASAP.
> [[email protected]]
>
> some time ago, i suggested it would be nice to be able to deselect
> entire submenus right at the top level. for example, it's clearly
> inefficient to have to select "Parallel port support" and bring
> up its corresponding submenu, if your only goal is to *deselect*
> that option.
Now that the menuconfig command extension to Kconfig has been merged,
I guess I could look into fixing the worst offenders.
--
Tomas Szepe <[email protected]>
> from my poking around in the whole Kconfig structure, it seems that the
> menu structure is tied awfully closely to the underlying directory
> structure. this would make it overly difficult to shift parts of
> the config menu around without dragging the corresponding directories
> around as well.
> <Sources are located regarding programming hierarchy _but_
> <relevant Kconfig can tune situation using 'depends' feature
> <at ease so that menuconfig, kernelserver ... have an optimized view
> <over kernel tree.OTOH a major problem resides in lack of functionnalities
> <especially when you don't know where to look at (ie.alphabetical order,
> <search engine....I'm adding those functions to kernelServer (wconf) ASAP.
KernelServer is cool, but it would be even nicer if it had a gopher
interface, because then you could make interfaces to very simple
devices indeed that can't handle HMTL, such as wristwatches, so that
you could, in theory, administer your boxes from anywhere in the
world.
Anyway, going back to the re-design of the kernel configurator, maybe
we have simply reached the practical limit of the simple menu based
system?
There are now so many options that you either have a lot of options
under vague headings, (which I prefer because I think that once you're
used to it, it's quicker and simpler), or, (in my opinion), excessive
levels of abstraction, and options deep within submenus, like:
Buses -> Internal -> Legacy -> ISA
There are also complications with taking configurations from old
kernel versions, and using them with later kernels - a 2.4 config
typically won't work simply by using make oldconfig on a 2.6 tree.
Maybe a completely new, out of kernel tree configurator would be worth
thinking about, leaving the in-kernel configurator as a legacy option.
I know the config system underwent a major overhaul during 2.5, but I
think we could go even further.
Ultimately, any configurator generates a plain text .config file with
various options set. There is no reason why we couldn't have a
modular system:
---------------------- ----------------
| Kernel .config | | Out of tree | ----------------
| options description|--->| configurator |--->| .config file |
| file | | | ----------------
---------------------- ----------------
/ / | | \ \
/ / | | \ \
^ v ^ v ^ v
/ / | | \ \
/ / | | \ \
---------------- ---------------- ----------------
| MODULE 1 | | MODULE 2 | | MODULE 3 |
---------------- ---------------- ----------------
The out of tree configurator on it's own would simply display all the
options in the kernel .config options description file, with their
descriptions, and allow them to be set to specific values. The
display could be colour coded for yes/no values.
The modules could allow things like:
* Creating a config file using an existing config file - similar to
make oldconfig
* Turning groups of options on and off - similar to the existing make
menuconfig, but more flexible - you could just load a 'bus options'
module, which would provide verbose prompting for bus options, allow
the turning on and off of groups of .config options, and hide advanced
options, but which would leave the raw .config options editable for
everything that wasn't to do with 'bus options'.
* Creating a minimal .config file from the output of boottime dmesg
output - similar to the adjustkernel perl script that works with
NetBSD:
http://www.feyrer.de/Misc/adjustkernel
Distributions could create their own modules to customise the
configurator however they wanted to.
John.
Hi,
On Fri, 25 Jul 2003, John Bradford wrote:
> Maybe a completely new, out of kernel tree configurator would be worth
> thinking about, leaving the in-kernel configurator as a legacy option.
> I know the config system underwent a major overhaul during 2.5, but I
> think we could go even further.
Maybe you should look first at something before you throw it away?
Kconfig is already modular, the Kconfig parser is a library, which you can
easily connect to your favourite script language and then you can do with
the Kconfig data whatever you want.
bye, Roman
> > Maybe a completely new, out of kernel tree configurator would be worth
> > thinking about, leaving the in-kernel configurator as a legacy option.
> > I know the config system underwent a major overhaul during 2.5, but I
> > think we could go even further.
>
> Maybe you should look first at something before you throw it away?
> Kconfig is already modular, the Kconfig parser is a library, which you can
> easily connect to your favourite script language and then you can do with
> the Kconfig data whatever you want.
Sorry, I meant make the current targets, like menuconfig and xconfig
legacy options, not eliminate the Kconfig parser altogether.
John.
On Fri, 25 Jul 2003, John Bradford wrote:
> Anyway, going back to the re-design of the kernel configurator, maybe
> we have simply reached the practical limit of the simple menu based
> system?
i see no evidence of that. i think Kconfig works fine. i just
think it's not being used in as structured a way as it might be.
> There are now so many options that you either have a lot of options
> under vague headings, (which I prefer because I think that once you're
> used to it, it's quicker and simpler), or, (in my opinion), excessive
> levels of abstraction, and options deep within submenus, like:
>
> Buses -> Internal -> Legacy -> ISA
i just want to point out that i never suggested *this* level of
sub-menuing, but even if i had, so what? typically, when you
rebuild a kernel, you don't go through the entire menu tree every
time. you typically want to tweak an option or two, so having
an extra level every so often is not going to be fatal.
what's important, i think, is to be able to look at the top-level
menu and be able to deduce quickly where to find the option you're
interested in. (pop quiz: without looking, where would you find
the option for the ftape floppy driver? see?)
(aside: i'm just breathless that someone could make a statement
like "a lot of options under vague headings (which I prefer ..."
you *prefer* vagueness? someone help me out -- is mr. bradford
really this clueless, or is he just trolling at my expense? i'm
pretty naive at times.)
> There are also complications with taking configurations from old
> kernel versions, and using them with later kernels - a 2.4 config
> typically won't work simply by using make oldconfig on a 2.6 tree.
oh, puhleeze. going from one major, stable release to the next one
should be considered such a big step that you shouldn't be surprised
if you might have to do a whole, fresh kernel configuration perhaps
that one time.
> Maybe a completely new, out of kernel tree configurator would be worth
> thinking about, leaving the in-kernel configurator as a legacy option.
> I know the config system underwent a major overhaul during 2.5, but I
> think we could go even further.
that does it. it's .procmailrc time for mr. bradford. life is too
short to listen to people criticize things they don't even
understand.
rday
> > Anyway, going back to the re-design of the kernel configurator, maybe
> > we have simply reached the practical limit of the simple menu based
> > system?
>
> i see no evidence of that. i think Kconfig works fine. i just
> think it's not being used in as structured a way as it might be.
>
> > There are now so many options that you either have a lot of options
> > under vague headings, (which I prefer because I think that once you're
> > used to it, it's quicker and simpler), or, (in my opinion), excessive
> > levels of abstraction, and options deep within submenus, like:
> >
> > Buses -> Internal -> Legacy -> ISA
>
> i just want to point out that i never suggested *this* level of
> sub-menuing
We are approaching it anyway, with more and more options being added.
> , but even if i had, so what? typically, when you
> rebuild a kernel, you don't go through the entire menu tree every
> time. you typically want to tweak an option or two, so having
> an extra level every so often is not going to be fatal.
Wrong. I compile kernels for lots of different machines, all the
time. I'm not just sat in front of one box, recompiling more or less
the same kernel all day. They are usually each configured from
scratch, except when there are several identical boxes.
> what's important, i think, is to be able to look at the top-level
> menu and be able to deduce quickly where to find the option you're
> interested in. (pop quiz: without looking, where would you find
> the option for the ftape floppy driver? see?)
Character devices. No, I didn't look first, by the way. It's been
there since at least 1.2.X.
> (aside: i'm just breathless that someone could make a statement
> like "a lot of options under vague headings (which I prefer ..."
> you *prefer* vagueness?
YES!!! Because it's only vague for people who aren't used to it.
> someone help me out -- is mr. bradford really this clueless, or is
> he just trolling at my expense? i'm pretty naive at times.)
Try looking at:
* My previous contributions to this list
* The bug database I've spent six months working on, on and off.
* My website
You decide whether I am a 'troll' or not.
> > There are also complications with taking configurations from old
> > kernel versions, and using them with later kernels - a 2.4 config
> > typically won't work simply by using make oldconfig on a 2.6 tree.
>
> oh, puhleeze. going from one major, stable release to the next one
> should be considered such a big step that you shouldn't be surprised
> if you might have to do a whole, fresh kernel configuration perhaps
> that one time.
Please don't talk down to me. The new users who you seem to be trying
to help, may well want to use their existing .config as a base for
their new one - moving from their distribution's 2.4 kernel to the 2.6
kernel may be the whole reason that they suddenly want to compile
their own kernel, whereas they have been happy with their
distribution's one up until now.
> > Maybe a completely new, out of kernel tree configurator would be worth
> > thinking about, leaving the in-kernel configurator as a legacy option.
> > I know the config system underwent a major overhaul during 2.5, but I
> > think we could go even further.
>
> that does it. it's .procmailrc time for mr. bradford. life is too
> short to listen to people criticize things they don't even
> understand.
Although I might criticize things, I provide code to back up my
criticisms. I didn't like the kernel Bugzilla, so I wrote an
alternative. More people use the kernel Bugzilla than my bug
database, so quite possibly I was wrong, _but_ instead of posting
hypothetical questions to this list, I wrote an alternative. It's
been mentioned in Kernel Traffic, a Linux magazine, and on lots of
websites.
John.
> [[email protected]]
>
> > Maybe a completely new, out of kernel tree configurator would be worth
> > thinking about, leaving the in-kernel configurator as a legacy option.
> > I know the config system underwent a major overhaul during 2.5, but I
> > think we could go even further.
>
> that does it. it's .procmailrc time for mr. bradford. life is too
> short to listen to people criticize things they don't even
> understand.
With all due respect, where tf do you get your pot?
On Fri, Jul 25, 2003 at 11:26:17AM -0400, Robert P. J. Day wrote:
> [some invaluable information zapped]
>
> what's important, i think, is to be able to look at the top-level
> menu and be able to deduce quickly where to find the option you're
> interested in. (pop quiz: without looking, where would you find
> the option for the ftape floppy driver? see?)
what about a search option, which actually grabs
for key words in descriptions, or a special keyword
list, with thematic structure?
> [some invaluable information zapped]
best,
Herbert