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 _______________________________________________ Devel mailing list [email protected] http://lists.laptop.org/listinfo/devel
