Modules vs. in-kernel?

[andrewski]

I saw on this message that Daniel Drake thinks that building important hardware into the kernel is a better idea than making modules. Kind of a revolutionary idea to a lamer like I am, who's always gone by the "when in doubt, build as module, unless needed at boot" rule....

What is the general consensus on this? Is Daniel just ultra-733T (no offense, I'm trying to be funny)? Or does he have a good point?

I have an NVIDIA video card, a Creative SB sound card, a madwifi-powered wifi card, and two hard drives. Should I build any of this into my kernel? Is there anything else that's not obvious that I should consider building in-kernel?

[Moriah]

There are good reasons for going either way. This is the Gentoo distribution of Linux -- the Burger King "have-it-your-way" Linux. How would you like your kernel, sir? Any fries with that?

Modules are favored by driver writers because you do not have to reboot to unload and reinstall a driver or other module. They are also essential for dynamic boot-time configuration and hotplugging. If you think you might ever have to repair a broken box by pulling a bad board and plugging a similar board of a different kind -- such as a video board -- then you want to use a module for that functionality.

Kernel resident is essential for things needed at boot time, before modules are loaded, unless you can use an initrd to load those modules. Kernel resident modules make for a faster boot time -- important for some high availability server applications. Kernel resident modules also eliminate the possibility that a successful intrusion exploit would also be able to substitute a hacked version of a module into your running system.

[andrewski]

Well, my system is just a desktop (ATM, hopefully a home server soon ) so the largest appeal is faster boot times. Since I usually just reboot when I update a kernel driver (except nvidia or madwifi), would I benefit to have other drivers reside in the kernel?

[Moriah]

I usually follow the KISS principle for workstations, as they are usually behind several layers of defense, and thus not as exposed to attack from outside, and they do not need such fast boot times, as usually only one person is waiting for them, not a whole corporation or all of its customers.

I would use modules for everything on a workstation unless you had an definite needs to have something kernel resident for boot, such as a particular filesystem type, or LVM, or EVMS, or RAID, etc., and that only if it applies to the root filesystem.

[Deranger]

I am using this rule: "Disable everything that you don't need" --> Resulting 1.4 MB kernel, all compiled in except iptables.

[Moriah]

So if you have a board fail, such as a disk controller, how do you boot your system if you have to replace it with a different type -- such as lets say you loose your SCSI board that runs your RAID on a server, and its the middle of the night on a weekend, and although the old board was a Bus-Logic, all you can find in the spare parts bin is an Adaptec? How do you boot the system after the board swap? Do you have to boot with a live CD, and the build another kernel? If you used modules and genkernel, this would not be necessary, thus getting the system back online faster.

[Moriah]

One more point: if you are building for a very tiny system, such as an embedded application, or a very old slow box with limited ram and disk size, them compile everything in you need, and nothing you don't need.

It is important to realize that, at least for most of my usual situations, the above is not the case. I prefer to keep things as flexible as possible -- unless I feel I have a good reason to do otherwise.

[popel]

put everything into the kernel that is realy stable:
- discdrivers
- network drivers
- usb driver
- ...

everything that is not that stable should be done as module.
examples:
- dvb driver
- graphics device drivers
- lirc
- and everything for ugly hardware.
normaly u know what makes problems. Modules alow u to reload/reset a brocken driver without reboot.

hope this helps
popel

[Moriah]

So if your ethernet board dies, and it was installed in the kernel, and you replace it with whatever you can get your hands on quickly, and its not the same kind, then you have to do a kernel build to get the network up.

This is especially inconvenient if you need to fetch a file over the network to do this, as you have no network to fetch it over.

Use modules unless you must use kernel resident!

[Moriah]

Or at least keep a bootable kernel in your /boot partition with a line in your /boot/grub/grub.conf that will let you boot a kernel that uses modules in an emergency.

[numerodix]

[Moriah]

Not all of the boxes here have a CD drive, and I have had *MANY* occasions when I tried to use a CD drive only to find out that the thing no longer worked.

I usually do my installs directly over the network, booting from some other distribution. I use redhat as a bootstrap loader to install gentoo if I have to start from scratch because I can install redhat from my local webserver with only 2 floppies.

I have only had a very few times when a floppy drive did not work, and some of my systems have all the IDE ports taken by disk drives, so there is not even any place to connect a CD drive in an emergency.

[Soul_rebel]

sometimes is nice to have usb as a module: for example it lets you "turn off" an adsl modem that has lost syncronization without having to be physically in the proximity... i have got a script that uses this for my router-server pc.
_________________
LinuX @ the Speed of Thought

[andrewski]

[Fitzsimmons]

[Moriah]

Good point!

But what if it was your disk interface instead of your ethernet board? You change the disk interface to a different brand, and you still have problems unless you used genkernel or some other boot-time hardware detection mechanism.

At the least, you must have another machine you can compile the necessary module on, and then you still have to use trinux or something like it to get the module on your boot disk so you can boot, assuming there is no cd drive on the sick box.

Moral: make an optimized kernel if you want to, but keep a genkernel around so you can boot in an emergency.

[andrewski]

[MK]

I prefer having as much as possible as modules, don't like having a static kernel, and modules isn't that much slower. Also I got lots of SCSI drives I don't use anymore, so I can load the module when I need the cdr etc, no need to wait for scsi drivers to load at boot. I also always keep a kernel where everything is compiled in, because of some bad experience in the past...

[numerodix]

[Deranger]

I have never used genkernel and I'm proud of it

LiveCD is definately the fastest way to deal all the problems.

[MighMoS]

For a server I have, I've disabled all modules, and module loading functionality, closing one way a hacker could gain full kernel access to my system . But for my desktop I still build most things into the kernel so I don't have to worry about hot/coldplugging, or stuffs like that. Its not mission critical, hardware doesn't die every week, and what's in there doesn't really move around. I know what I use my box for, so I don't need every possible option. For me it just makes sense to build it into the kernel.
_________________
jabber: MighMoS@jabber.org

localhost # export HOME=`which heart`

[Fitzsimmons]

[tuber]

[Fitzsimmons]

I believe it would be

[Archangel1]

I haven't bothered to modularise everything on mine. If by some freak a bit of hardware died, and both CD drives nuked themselves so I couldn't restore off a LiveCD, there's a fair chance the computer won't be usable *anyway* because it's been dropped or hit by a power spike or something. I'm not likely to fix it by compiling new modules inside the existing system.

Some things are necessary as modules though; USB on a laptop springs to mind (the modules are removed before suspending), and ALSA apparently likes modules better, although I've heard of it working fine built-in.

And of course the nVidia drivers; if not for them I could probably set up my desktop without module loading capability.