Compiling as modules: useful always?
 

Hi,

Should I maximize the amount of code that I compile as a module?
Is it a better use of resources to compile say my ethernet card's driver as a module or should something so often-used go into the kernel?


Thanks!
-Mike

I'm not at all a kernel-hacker, so take all this with a grain of salt.

Kernel modules are most useful for flexibility:

• For instance, if you're building a kernel that might run on many different systems (say for a bootdisk), then you want to build a flexible kernel and package different sets of modules in different initrds. You plug in the pieces you need at runtime as and when you need them.
• You can also unload them when you're done with them. That's a somewhat uncommon situation: in regular desktop use, for example, you're probably not going to unload your ethernet card driver after you load it in. But in special circumstances that can happen, and when it does, modules will save you some memory (the base kernel stays in memory; modules don't).
• This also means you can upgrade your hardware without rebuilding your kernel or rebooting your system. Which is really cool but again, it doesn't happen every day.

The disadvantages are:

• When you build the kernel, you could end up with all this crud lying around that you don't really need (for instance, building a PCMCIA module when you only really need the EtherExpress Pro/100 module).
• Security risk: if modules can be loaded, malicious modules can be loaded. If you have a streamlined monolithic kernel that doesn't allow any later additions then you're that much safer. Just as when you're hardening a server you want to put in stuff you need, get rid of stuff you don't need, and then lock it down; you don't want to put in stuff just because you *might* use it someday. I think some rootkits are deployed as loadable kernel modules.
• In a few (rare) instances there can be a performance hit.

TLDP has a page on kernel modules: http://www.tldp.org/HOWTO/Module-HOWTO/

Bottom line: if you're a regular home user it doesn't matter either way and you're probably better off with the flexibility of modules. If you have a stable box and you're not going to keep adding or removing hardware and you want a somewhat tighter system, a monolithic kernel is a good idea. If you're developing/playing with lots of toys, modules are a good idea.

GR


(Of course, all this is for a kernel that was originally meant to be monolithic, like Linux. For a fundamentally modular/microkernel system like the Hurd, you can't live without modules. They also have some really cool ideas like "translators" (ie. modules) that can be attached to any file, but then they have an OS that has been coming out "next year" for 20 years now.)

Additionally, one thing that speaks for using modules for certain kernel features is that you can pass options to them as you load them. For instance some sound cards are very tricky and their drivers need a *lot* of parameters passed to them in order to work. If you configure your kernel with the driver built in you will need to pass the options at boot-time, and if it takes twenty tries to get it working you'll be really unhappy rebooting a 21st time in order to see if it works. When having the driver compiled as a module you can try specifying the different parameters on the command line until you get it right. When you do get it right, simply add them to your distribution's means of module parameter passing (nowadays mostly meaning your modprobe.conf file).

I have had a lot of tricky hardware (mostly sound chips in laptops) and having the driver statically compiled in the kernel is a real pain when configuring.

Håkan