linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: "Robert P. J. Day" <rpjday@mindspring.com>
To: Embedded PPC Linux list <linuxppc-embedded@ozlabs.org>
Subject: cleaning up the Kconfig menu structure -- the bigger picture
Date: Fri, 8 Oct 2004 07:16:18 -0400 (EDT)	[thread overview]
Message-ID: <Pine.LNX.4.60.0410080704170.6219@dell.enoriver.com> (raw)


   somewhat related to dan malek's posting, but i think part of the 
problem with trying to figure out what the menuconfig menus should 
support is that the relevant options are organized in a confusingly 
haphazard way.

   if you're building a kernel for an 8xx system, obviously you'll 
choose the 8xx processor, at which point naturally a number of other 
kernel config menu entries (dependent on the "8xx" config variable and 
falling off of that) suddenly become visible.  unfortunately, in 
really badly-chosen places.

   consider, first, serial port options.  if you choose 8xx, then 
you'll be presented with the menu choices:

   Device Drivers -->
     Character devices -->
       Serial drivers -->
         CPM SCC/SMC serial port support --> etc, etc.

now, is this the right place for configuring CPM SCC/SMC serial port 
support?  sure, some people might say.  after all, it's serial port 
stuff, it should be under "Serial drivers".  makes perfect sense, 
right?

   in that case, if you wanted to configure "CPM SCC Ethernet", why 
would you go under "MPC8xx CPM Options" rather than the general 
networking menu?  this is clearly inconsistent.

   more to the point, i've always found it a bit strange that selecting 
"8xx" as a processor would suddenly cause the top-level "MPC8xx CPM 
Options" menu to appear, when other 8xx-related stuff was still 
scattered elswewhere throughout the kernel source tree.

   it might make more sense, if you choose "8xx", to have *all* 
8xx-related stuff to suddenly appear under a single top-level menu: 
serial ports, networking, patches, etc.  at least, you'd get to see 
everything in one place, and calculating interdependencies would be 
simpler (no, you can't choose SMC1 to be both a serial port and an 
ethernet, that sort of thing).

   i don't know if this suggestion is feasible but, really, it seems 
clear that the current menu structure is pretty ad hoc and 
disorganized.

   thoughts?

rday

             reply	other threads:[~2004-10-08 11:23 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-10-08 11:16 Robert P. J. Day [this message]
2004-10-08 15:31 ` cleaning up the Kconfig menu structure -- the bigger picture Dan Malek
2004-10-08 15:38   ` Robert P. J. Day
2004-10-08 16:37     ` Dan Malek
2004-10-08 16:31       ` Robert P. J. Day
2004-10-08 16:40 ` Tom Rini
2004-10-08 16:42   ` Robert P. J. Day
2004-10-08 17:22   ` Dan Malek
2004-10-08 18:02     ` Tom Rini
2004-10-08 18:39       ` Dan Malek
2004-10-08 19:48         ` Tom Rini
2004-10-08 20:49           ` Dan Malek
2004-10-08 21:38             ` Tom Rini
2004-10-08 22:03             ` Wolfgang Denk

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=Pine.LNX.4.60.0410080704170.6219@dell.enoriver.com \
    --to=rpjday@mindspring.com \
    --cc=linuxppc-embedded@ozlabs.org \
    /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;
as well as URLs for NNTP newsgroup(s).