archive mirror
 help / color / mirror / Atom feed
From: "Robert P. J. Day" <>
To: Linux kernel mailing list <>
Subject: why the current kernel config menu layout is a mess
Date: Thu, 24 Jul 2003 20:56:53 -0400 (EDT)	[thread overview]
Message-ID: <Pine.LNX.4.53.0307242020140.23200@localhost.localdomain> (raw)

  (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?

"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

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

"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

"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

  anyway, i could go on but i'm sure you get the idea.  this
current layout could use a major overhaul.


             reply	other threads:[~2003-07-25  0:43 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-07-25  0:56 Robert P. J. Day [this message]
2003-07-25  1:27 ` why the current kernel config menu layout is a mess Bernd Eckenfels
2003-07-25 12:46   ` Robert P. J. Day
2003-07-25 14:10     ` Tomas Szepe
2003-07-25 13:18 Frederick, Fabian
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 15:28 John Bradford
2003-07-25 15:53 John Bradford

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.53.0307242020140.23200@localhost.localdomain \ \ \

* 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;
as well as URLs for NNTP newsgroup(s).