# 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  :Razz: ) 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.    :Surprised: 

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.  :Very Happy: 

----------

## 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.  :Surprised: 

----------

## 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.   :Very Happy: 

----------

## numerodix

 *Moriah wrote:*   

> 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!

 

You keep insisting on modules being so much better but what's the big deal about whipping out the livecd in a hardware emergency/replacement situation? It's not like it happens often.. does it?

----------

## 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.  :Surprised: 

----------

## 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.

----------

## andrewski

 *Moriah wrote:*   

> 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!

 But if I have a kernel custom-compiled for my system and I put something in that's not in my kernel, it won't matter whether it's a module or not; it won't be there and I'll have to resort to something else anyway.

----------

## Fitzsimmons

 *Moriah wrote:*   

> 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.  
> 
> [snip]
> 
> 

 

No you don't!  You just compile the module for the new ethernet board and modprobe it.  You don't need to build the whole kernel again, just the modules.

----------

## 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

 *Moriah wrote:*   

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

 Ah, but to be sure, that's something different than you've been saying the last few posts.  That (in my head, anyway) seems like a good moral.

----------

## 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

 *Moriah wrote:*   

> 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. 

 

Well if your setup is that particular, maybe you should have stated those reasons in your argumentation?  :Wink: 

For most desktop users, I would imagine genkernel is a bit unnecessary for daily use. Not only does it take longer to boot because of the hardware auto-detection, it also takes ages to compile because you need boatloads of modules. I suppose for servers it doesn't matter whether it takes a minute or three minutes to boot cause you're not sitting around waiting for it to boot anyway. And you probably don't reboot often, so why not genkernel.

----------

## Deranger

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

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  :Very Happy: .  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.

----------

## Fitzsimmons

 *MK wrote:*   

> 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...

 

Actually I've heard that modules are actually slightly faster than builtin.  However, I've also heard that -ffast-math and -funroll-loops are good ideas, so like everything else, I took it with my obligitory salt.

----------

## tuber

 *Fitzsimmons wrote:*   

> 
> 
> No you don't!  You just compile the module for the new ethernet board and modprobe it.  You don't need to build the whole kernel again, just the modules.

 

So if I decide that I want to enable a module that was previously disabled, I can just run "make menuconfig" (or something), enable the module, skip making the kernel, and go directly to "make modules_install" and modprobe with the currently running kernel?

----------

## Fitzsimmons

I believe it would be 

```

#make modules modules_install

```

but otherwise, yes.

----------

## 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.

----------

## Bob P

 *Moriah wrote:*   

> 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. 

 

i have never used a genkernel, and i don't plan to ever use one.    :Wink: 

regarding the drive controller failure that you've described, i think that any network support engineer that finds himself in that sort of situation has failed to plan for a basic system failure and isn't worth his paycheck.  

if you've got a mission critical server that goes down on a weekend and you try to blame downtime on having to recompile a kernel instead of having replacement parts on-hand, or if you find some other lame excuse, like not having planned redundancy, then you deserve to be sitting in the board room with Donald pointing the finger at you.

i do like your idea about keeping a genkernel available as a Grub boot option.  that way, you won't have to wait for the new kernel to compile as you're clearing your belongings out of your cubicle and stuffing them into a cardboard box.   :Embarassed: 

----------

## Moriah

Sometimes you have already been in the boardroom pointing the finger at Donald and saying you need the budget for that redundancy, and he says, "What are the chances".  So you tell him, and he says, "We'll take our chances."

Times are tough, and budgets are tight.  Spare parts on the shelf look like wasted money to non-techies.  They think these things gradually go bad and we can order new ones before the old ones quit altogether.  This may sometimes be true (if you are lucky) with a disk drive, and critical systems use RAID anyway, giving you some security, but other parts can be unique to a given system, because of its function or its age.  You can't spare everything.  If I could, I would have only 2 or 3 standard configurations to support, but reality says you need a machine and you go scrounge up whatever you can find thats lying around not doing anything.  Then you have to install and configure it.  It all takes time.

I had the motherboard IDE controller go flakey Thanksgiving Day on the gateway firewall machine.  *GROAN*!  I had to grab a very old machine and configure it to do firewall duty.  It is up now, but Thanksgiving got hectic at around 2 PM here.   :Sad: 

Can you say COLD TURKEY?  :Evil or Very Mad: 

And to make matters worse, the Wednesday before Thanksgiving, MCI lost the feed line for 8 hours, so we were offline most of Wednesday too.

----------

## Bob P

it must really suck for MIS to be critically undercapitalized in an era when PC parts are so cheap. 

for pete's sake -- i'm a homeowner and i have enough spare parts on hand to build an extra scsi based server.

using your example of a mission critical PC that's needed to serve the business's web based clients, if the guys in the boardroom are too cheap to buy a spare controller card for a PC, and their order system crashes, the company deserves to go banrkupt because of shitty management.  its just too bad that you can't fire those assholes when you're right and they're wrong.    :Wink: 

----------

## carvell

 *andrewski wrote:*   

> Is Daniel just ultra-733T?  Or does he have a good point?

 

The former.

HTH.

----------

## Moriah

Earlier in this thread I said: *Quote:*   

> Sometimes you have already been in the boardroom pointing the finger at Donald and saying you need the budget for that redundancy, and he says, "What are the chances". So you tell him, and he says, "We'll take our chances." 

 So when I saw this, I just had to share it:

http://www.unitedmedia.com/comics/dilbert/archive/images/dilbert200411295108.jpg  :Very Happy: 

----------

## thecrazyperson_ws

I take a philosophy that quite possibly many others here take.  if it's needed to boot the machine, compile it in, and if it's not, then make it a module then add it to /etc/modules.autoload.d/kernel-2.6.  that way, if say, I have a network controller die, at least the machine will still boot so I can add the module for the other network card (assuming it's something other than the 8139too-based card i have now).  following this philosophy has led me to a 1.8 meg base kernel which loads no more than another 300 K of modules at startup.

----------

## Bob P

 *Moriah wrote:*   

> So when I saw this, I just had to share it:
> 
> http://www.unitedmedia.com/comics/dilbert/archive/images/dilbert200411295108.jpg 

 

seems very appropriate!    :Wink: 

----------

## Codo

I apologize for my ignorance here...  What about memory?  In what area of memory modules are loaded?  I suppose if it is compiled in the kernel the kernel starts to get big...?

----------

