Kernel configuration options

[John Richard Moser]

I'm not sure about some of the kernel configuration options.  A few 
minor things stick out in my mind; I don't know the rationale behind 
some of these things and am curious about developer decisions and 
thoughts on how to build the kernel.

  * CONFIG_NO_HZ + CONFIG_HZ=100?
  * SLAB vs SLUB
  * Some debugging stuff
  * More debugging stuff
  * Building stuff as modules

First off I noticed CONFIG_NO_HZ=y and CONFIG_HZ=100; is this a quirk of 
the kernel's general configuration?  As I understand, these options 
should be mutually exclusive because CONFIG_HZ is a parameter of a 
scheduler using a different methodology than CONFIG_NO_HZ...

Another thing is I noticed CONFIG_SLAB=y, but the SLUB allocator is 
supposed to be a faster generic replacement for SLAB.[1]  Is there a 
reason the XO doesn't use it?

I'm also noticing some things like KALLSYMS and BUG(), BSD process 
accounting, and the like.  KALLSYMS, BUG(), and printk() are useful; on 
a true embedded device I'd say remove 'em but I can't justify it here... 
BSD process accounting and auditd support though?

In the same line, a lot of debugging options are in use.  I'm using 
Build 653, I guess it may be a developer's build and thus there's a lot 
of debugging stuff; but in the final should things like CONFIG_PROFILING 
, CONFIG_KPROBES, CONFIG_DEBUG_FS, CONFIG_UNUSED_SYMBOLS, 
CONFIG_SCHEDSTATS, CONFIG_TIMER_STATS, CONFIG_DEBUG_PREEMPT, 
CONFIG_DEBUG_SPINLOCK ... be removed?

Finally, I'm noticing a lot of stuff can be built as modules, but is 
built in.  Networking in its entirety; sound drivers; mouse; and USB 
(the mouse looks like it's PS2) can be loaded by HAL and UDEV, but this 
will increase boot time (then again, HAL apparently needs to be fixed 
anyway[2], so this could be encouraging?).  More interesting to me 
however is that EXT2, EXT3, Joliet, ZISOFS, RAMFS, NFS, and possibly 
PROMFS because I don't think JFFS2 depends on it BUT I'm not sure if 
it's used at some point before it can be loaded as a module.

[1] http://lwn.net/Articles/229984/
[2] http://lwn.net/Articles/192214/
-- 
Bring back the Firefox plushy!
http://digg.com/linux_unix/Is_the_Firefox_plush_gone_for_good
https://bugzilla.mozilla.org/show_bug.cgi?id=322367