There's nothing like rolling your own kernel, compiled your way, to eliminate diagnostic variables. Please realise that the main reason for the prevalence of highly modular kernels and initial RAMdisks is so that distributions can install and run with a single installation set onto the widest possible range of hardware. As a result, such setups aren't guaranteed to work on your hardware, and are pretty much guaranteed to be sub-optimal even where they do.

What the distributions are trying to get away from is the traditional Slackware installation routine, where you select a boot floppy image and a root floppy image from among dozens of such combinations, picking a pair that's appropriate for your hardware. That still works. In fact, it works extremely well. But it doesn't sell to the masses. Thus the profusion of modules and initrds.

After any successful installation, I still, to this day, like compiling a kernel that has all its required hardware drivers, filesystem drivers, and optional features compiled directly into a monolithic kernel that doesn't even support module-loading at all. But short of that, you can alternatively compile a kernel that support modules, and has at its disposal a big tree of modules, but has support for key hardware and filesystems compiled directly in.

The latter can be a lifesaver, e.g., if you suddenly do something that screws up your kernel's ability to load and unload modules, or clobber /lib/modules/[foo], or some bonehead manoeuvre like that. Having crucial drivers compiled directly into the kernel means they're available no matter what, as long as the kernel gets loaded and is running at all.

Rick Moen
rick@linuxmafia.com

Scott wrote:

FS, network, and essential hardware is compiled into the kernel. Other things that may or may not be needed at some point in time are done as modules. No initrd needed, but modules are still available.

It's a good compromise: It lets you try new things and have them be supported pretty much automatically, while ensuring that core drivers (ones you know you're likely to need for a long time) are always present. All you lose is a little disk space in /lib/modules -- and the tinfoil-hat paranoic's assurance inherent in non-module-supporting kernels. (One security theory goes that there's a slight security threat in modular kernels, in that the bad guys could hide their presence via a trojaned module in a way much more difficult to detect than via a presence in userspace.)

Rick Moen
rick@linuxmafia.com