linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* RE: why the current kernel config menu layout is a mess
@ 2003-07-25 15:28 John Bradford
  0 siblings, 0 replies; 12+ messages in thread
From: John Bradford @ 2003-07-25 15:28 UTC (permalink / raw)
  To: john, zippel; +Cc: ecki-lkm, Fabian.Frederick, linux-kernel, rpjday

> > 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.

^ permalink raw reply	[flat|nested] 12+ messages in thread
* RE: why the current kernel config menu layout is a mess
@ 2003-07-25 15:53 John Bradford
  0 siblings, 0 replies; 12+ messages in thread
From: John Bradford @ 2003-07-25 15:53 UTC (permalink / raw)
  To: john, rpjday; +Cc: ecki-lkm, Fabian.Frederick, linux-kernel

> > 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.

^ permalink raw reply	[flat|nested] 12+ messages in thread
* RE: why the current kernel config menu layout is a mess
@ 2003-07-25 14:58 John Bradford
  2003-07-25 15:07 ` Roman Zippel
  2003-07-25 15:26 ` Robert P. J. Day
  0 siblings, 2 replies; 12+ messages in thread
From: John Bradford @ 2003-07-25 14:58 UTC (permalink / raw)
  To: ecki-lkm, Fabian.Frederick, rpjday; +Cc: linux-kernel

> 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.

^ permalink raw reply	[flat|nested] 12+ messages in thread
* RE: why the current kernel config menu layout is a mess
@ 2003-07-25 13:18 Frederick, Fabian
  0 siblings, 0 replies; 12+ messages in thread
From: Frederick, Fabian @ 2003-07-25 13:18 UTC (permalink / raw)
  To: Robert P. J. Day, Bernd Eckenfels; +Cc: linux-kernel

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.

^ permalink raw reply	[flat|nested] 12+ messages in thread
* why the current kernel config menu layout is a mess
@ 2003-07-25  0:56 Robert P. J. Day
  2003-07-25  1:27 ` Bernd Eckenfels
  0 siblings, 1 reply; 12+ messages in thread
From: Robert P. J. Day @ 2003-07-25  0:56 UTC (permalink / raw)
  To: Linux kernel mailing list


  (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

^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2003-07-25 15:55 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-07-25 15:28 why the current kernel config menu layout is a mess John Bradford
  -- strict thread matches above, loose matches on Subject: below --
2003-07-25 15:53 John Bradford
2003-07-25 14:58 John Bradford
2003-07-25 15:07 ` Roman Zippel
2003-07-25 15:26 ` Robert P. J. Day
2003-07-25 15:51   ` Tomas Szepe
2003-07-25 16:11   ` Herbert Pötzl
2003-07-25 13:18 Frederick, Fabian
2003-07-25  0:56 Robert P. J. Day
2003-07-25  1:27 ` Bernd Eckenfels
2003-07-25 12:46   ` Robert P. J. Day
2003-07-25 14:10     ` Tomas Szepe

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).