cleaning up the Kconfig menu structure -- the bigger picture

Robert P. J. Day rpjday at mindspring.com
Fri Oct 8 21:16:18 EST 2004


   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




More information about the Linuxppc-embedded mailing list