# Using modules vs. monoholitic kernel

## Geralt

Hi,

which one do you favor and why?

Until recently I've got a monoholitic kernel, because I know what drivers and subsystems I need, so it made sense to build everything into the kernel and I don't have to waste time at boot-up when the genkernel-package's initramfs' script is loading most of them anyway.

But up to today I've had several times where I either was missing a driver (dcdbas for example, needed it to access bios settings) or wished I could just rebuild and re-install the driver at load-time.

So how do you handle it? I'm considering switching some drivers back to modules.

----------

## szczerb

I have everything I can built it - it's easier this way. I have fuse as a module (fusesmb needs it to be a module) and snd_hda_intel (it needs a parameter so I think there's no other way then a module...) and everything that need's to be reloaded after hibernation (iwl3945 and sdhci).

(sdhci forced sdhci_pci and ricoh_mmc to be modules aswell)

----------

## Naib

I prefer have monolithic JUST for what is needed for init to kick off then everything as modules.

Having virtually everything as modules helps in a number of ways

1) I can help others since they go "Oh I have this hardware what module do I need" my lsmod will be of use to them

2) IF I have forgotten something (eg UDF for reading DVD's) I can just go into the kernel config and build that and modprobe it. IF you go for a monolithic you need to reboot

Basically I use to like Monolithic but I was running into more issues (eg rebuild and reboot) then I have in going for a vritually all modular

----------

## NeddySeagoon

I use monolithic on my server, with module loading disabled as it removes an attack vector.

Everywhere else I'm with Naib.

Modules also make it easier to pass parameters, as you can use modprobe -r <module> to do trial and error.

Contrast that with passing parameters to a monolithic kernel. That needs a reboot.

----------

## Paczesiowa

 *szczerb wrote:*   

> I have everything I can built it - it's easier this way. I have fuse as a module (fusesmb needs it to be a module) and snd_hda_intel (it needs a parameter so I think there's no other way then a module...)

 

my fusesmb works with fuse builtin. as for snd_hda_intel, read first page of /usr/src/linux/Documentation/kernel-parameters.txt

----------

## pdw_hu

Mostly I modularize all the stuff i rarely use. FireWire, Bluetooth, some filesystems, UDF, etc. I also blacklist them as i never used firewire (but might need it one day). Everything else is in the kernel...

----------

## szczerb

Paczesiowa so it could've been ntfs-3g that needed it - in docs for one of those I found that fuse should be a module so I just enabled it and didn't even check if it works otherwise. Thanks a lot for the parameters info - didn't know  :Smile: 

----------

## RedSquirrel

There is a FAQ entry for this topic.

My kernel is monolithic. I like having everything packed into a neat little bundle. It is pretty small and boot time is acceptable.

----------

## Paczesiowa

 *szczerb wrote:*   

> it could've been ntfs-3g that needed it

 

ntfs-3g also works with fusesmb compiled-in. and sshfs, and rarfs and many other fuse filesystems I use.

----------

## szczerb

Good to know - maybe some older version needed it this way...I  don't really remember where and when I read this ;]

----------

## sundialsvc4

I build-in to each kernel all of the hardware-support that I know is required for a particular machine's "permanent" hardware.  (You can usually determine this by starting Knoppix or somesuch, then noticing what drivers it has auto-selected...)

Then, I use modules for anything that is either removable, or optional.  For example, I might need any one of several crypto-algorithms for different VPN connections, but I won't need all of them at once.  I don't need driver support for my USB-attached camera except when that camera is actually attached, and so on.

Because my Linux configuration is very specific to the hardware on which it runs, and to precisely what I'm using a system for, all of my systems can go from full power-off to fully operational in much less than one minute.  There is no "hardware discovery," and no cruft.

----------

