# kernel compilation doubt: modules?



## fluca1978 (Mar 13, 2012)

Hi,

*T*his could sound trivial, but when I configure a new kernel how can I decide (if possible) what is going to be a loadable module and what is going to be included into the kernel itself?


----------



## Bunyan (Mar 13, 2012)

One may include in the kernel whatever is possible and needed for everyday use of the system: linux support, various file systems support, sound, graphics cards, ATA/SATA chipsets, ethernet NIC support, UFS journaling, ethernet bridging, firewall (ipfw, ipfilter, pf), provided there is a working firewall config, etc.
Still, there is code that is available only as modules, like ZFS support

/sys/conf/NOTES makes a good reading for this purpose.


----------



## kpa (Mar 13, 2012)

I would say that on amd64 and with enough system memory there's very few reasons (PF ALTQ etc.) to compile your own kernel, GENERIC will provide the same performance you would get with your own custom kernel and the amount of wasted memory by unused drivers isn't really that much. If you're on i386 it's much more beneficial to strip unused drivers because i386 has a limited address space for kernel memory unlike amd64.

First things to change to loadable modules are nic drivers you know you'll never have on your system, same with drivers for various SCSI controllers.


----------



## Bunyan (Mar 13, 2012)

Hey, man.
Just a  question:
-Why should I not remove from the kernel ALL code that I'll NEVER need?


----------



## throAU (Mar 13, 2012)

Bunyan said:
			
		

> Hey, man.
> Just a  question:
> -Why should I not remove from the kernel ALL code that I'll NEVER need?



Because:

These days, it saves minimal memory, in the context of how much memory you have in your box
You may not realise that you need a feature one day, and then you're back to recompiling a kernel again, possibly after spending significant time (both admin time, and server down-time) troubleshooting an issue that would not have occurred if you were using GENERIC.


When considering the first point vs. the second point, many would suggest that it is not worth messing about.  I'm in that camp myself - unless there is some feature NOT included in GENERIC that I need in a particular box, I'll use GENERIC.  GENERIC is well tested, has sensible defaults that work in 99% of cases, and I know that nay potential weird and wonderful errors weren't caused by dodgy compile time options on my behalf.


----------



## SirDice (Mar 13, 2012)

fluca1978 said:
			
		

> this could sound trivial, but when I configure a new kernel how can I decide (if possible) what is going to be a loadable module and what is going to be included into the kernel itself?



It's fairly simple actually. Everything that's not built into the kernel will be built as a module.


----------



## fluca1978 (Mar 13, 2012)

It is still not clear to me, allow me to explain with an example:


```
#device         ispfw      # Firmware for QLogic HBAs- normally a module
```

Now if I enable such device a module, as stated from the documentation, will be generated, right? Now, how can I force this to be a module instead of being built into the kernel? I read the documentation here but I cannot understand how the two cases are discriminated.


----------



## SirDice (Mar 13, 2012)

> Now, how can I force this to be a module instead of being built into the kernel?


You don't. Actually _everything_ is built as a module, including the stuff that's built into the kernel.


----------



## fluca1978 (Mar 13, 2012)

What is the rationale of having all compiled as a module and loaded and linked at runtime? I mean, other kernels (e.g., Linux - not meant to start a flame here!) allows for some pieces to be linked directly within the kernel.


----------



## jalla (Mar 13, 2012)

@fluca1978 I think you misunderstand. If you put, say ispfw, in the kernel config it is linked directly into the kernel *and* also built as a loadable module (totally useless, but thats a different matter).


----------



## wblock@ (Mar 13, 2012)

Modules are built for everything.  Devices listed in the kernel config file are also built into the kernel.  Because most modules can be loaded at runtime, it's not necessary to have everything built into the kernel any more.  If you need something only once in a while, leave it out of the kernel and kldload(8) the module just when necessary.


----------



## SirDice (Mar 14, 2012)

jalla said:
			
		

> @fluca1978 I think you misunderstand. If you put, say ispfw, in the kernel config it is linked directly into the kernel *and* also built as a loadable module (totally useless, but thats a different matter).



Yes, that's exactly what I meant.

I have, for example, re(4) build into my kernel. But it also created /boot/kernel/if_re.ko.


----------



## fluca1978 (Mar 16, 2012)

So in order to not allow a module to be loaded I have to not include such option in the kernel config and remove the module from the disk, right? Or is there another way to config a kernel to not accept at all modules?


----------



## SirDice (Mar 16, 2012)

If you set kern.securelevel to 1 kernel modules cannot be loaded or unloaded. See security(7).


----------



## wblock@ (Mar 16, 2012)

fluca1978 said:
			
		

> So in order to not allow a module to be loaded I have to not include such option in the kernel config and remove the module from the disk, right? Or is there another way to config a kernel to not accept at all modules?



The question is unclear.  Modules are only loaded in /boot/loader.conf or manually with kldload(8).  If a module is not needed, don't include it in the kernel config or load it.  It does not need to be removed from the disk.


----------



## fluca1978 (Mar 17, 2012)

Thanks, the securelevel was the option I was looking for. It is now all much more clear.


----------

