Testing 2.6.26 on a GTA01

Andy Green andy at openmoko.com
Mon Aug 4 12:23:24 CEST 2008

Hash: SHA1

Somebody in the thread at some point said:
| Cesar Eduardo Barros wrote:
| [...]
|  > I haven't tested the peripheral chips (GSM, BT, GPS); however, sound
|  > works (this defconfig has everything built-in instead of using modules,
|  > which is much better than having sound as a module).
| [...]
| Hello.
| Can anyone tell me (or point me to some documentation) why it's better
| to have mostly static kernel than using modules (for a FreeRunner's
| kernel)?

I wouldn't say it is just "better", each way has some advantages.

Static kernel

~ - the devices are up before you bring up your rootfs.  So you have the
possibility to use the driver features to provide the rootfs.  This is
why many modules have to be in the monolithic kernel, like jffs2, ext2,
vfat, mtd, sd card...

~ - you can do testing without needing to keep the rootfs /lib/modules in
sync with anything, it's a bit faster if you compile and try hundreds of
kernels a week which happens here.


~ - You don't need to take up space for the code and data in memory
unless you needed it.  For example, if you simply don't use ipv6, you
can save hundreds of KBytes by not having the modules in.

~ - As we saw recently, some drivers are mutually exclusive.  We put
Ethernet over USB gadget into the monolithic kernel, it meant you could
never use the other gadget drivers.  So pushing the mutually exclusive
set out into modules allows the end user to configure how and when he likes

~ - For some development, it is much quicker to put the driver in a
module and keep updating it against the same kernel.  It means you just
modprobe -r the old module, scp the new one, and modprobe it in again
without rebooting.

- -Andy
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org


More information about the openmoko-kernel mailing list