A recent thread on the OpenBSD project’s misc@ mailing list discussed why OpenBSD has chosen to stick to a purely monolithic kernel, instead of trying to optimize performance by using kernel modules. As described in the OpenBSD FAQ, the OpenBSD team only supports the GENERIC kernel that is provided with the distribution. Numerous reasons were provided, including security, the ability to fully test, and simplicity.
OpenBSD: Monolithic Simplicity
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Since when do modules == higher performance?
Am I missing something?
NetBSD does have LKM support, and I think that is a good thing, because otherwise the GENERIC kernel would be 11 MB. And that is a bit too large, I think.
But as the GENERIC kernel of OpenBSD is only 5 MB, I indeed don’t really see the point of supporting LKM’s. And using them for hardware support could also make things less plug-and-play.
Btw. without LKM’s, you still need to test a kernel more than once – you should try it on as many computers as you need to have all drivers activated and used at least once.
Possible reasons:
[ ] Maybe because the kernel loads faster if it is smaller?
[ ] Maybe the computer runs faster because less RAM is wasted on unused drivers?
[ ] Other: …
Are they saying that they do not like the idea of dynamically loading a kernel module? Huh?
If I might be cynical… Lets see, why not compile the application directly to the operating system. Compile everything into one huge application. Then it would be really fast to load, etc!
Seriously, if your OS does not have to support many configurations, then why not! However, if your OS is going to support many device drivers, and support many contexts there is no way around and LKM. Also LKM’s are useful when your team consists more than a small group of people.
It is like trying to make the argument that you do not need shared libraries…. Sure sometimes they are a pain, but they are better.
Loadable kernel modules have nothing to do with it being monolithic or not.
Is that an argument against LKMs?
Why not use LKMs:
1. Plenty of rootkits for Linux these days use kernel modules to help hide what they are doing. -security
2. Harder to debug. As has been mentioned in the thread (yes, I’ve been reading the entire thing), finding out why the module borks when you load it the second time but not the third time can be a pain. -development
3. Encourages hardware companies to release modules for their hardware instead of releasing documentation. -relion
4. Encourages people to edit the kernel configuration to no end creating a large amount of variations. This would be almost impossible to thoroughly test. -again, development
OpenBSD does have support for LKMs, but they don’t bother to test it.
1. How much time does tracking down worthless kernel module errors take for you? It takes me a while if I worry about it on my Linux system.
2. How much difference do you think 2-3MB of RAM makes on a modern system?
LKMs have nothing to do with being monolithic
If u wanna save memory recompile ur kernel to have drivers only for ur devices. That way I wont have problems accompanying loading modules plus I save memory.
Since when NetBSD has a 11MB kernel? IIRC a GENERIC one is ~5-6MB, nowadays I’m using NetBSD-2.0_BETA (i386,sparc) and my kernels aren’t bigger than 3MB (the i386 machine is a recent Athlon-xp). Actually the only LKM I’m using is aperture which enables me to run XFree86 without the INSECURE kernel option.
Anyway, what’s the advantage to run a little kernel if you need a lot of modules because your computer has a lot of hardware? I see modules useful when you got many USB/PCMCIA/etc hardware which can be easily (un)plugged so you don’t need this support always, just when the hardware is plugged in.
Finally, like Russell Jackson said, I think monolithic are all the kernels commented here (with or without LKM) or is anyone trying to compare modules with microkernel ? :^)
I run NetBSD 2.0_beta too, and the GENERIC kernel of it is 7.4 MB with an additional 3.5 MB of LKM’s (cd9660, ntfs, compat_linux, ext2fs, smbfs and more), so that adds up to 11 MB.
A custom kernel can be much smaller indeed, but that is not what we are talking about here.
— Here the complete output of my investigation – a recent NetBSD 2.0_beta snapshot —
$ ls -l /netbsd
-rwxr-xr-x 1 root wheel 7480711 May 18 10:46 netbsd
$ du -sh /usr/lkm
3.5M /usr/lkm
Ok, I was wrong, but in a GENERIC kernel you have cd9660, ntfs, compat_linux, ext2fs, smbfs,etc support active so you are duplicating this support. Finally we got a ~7MB kernel.
I run NetBSD 2.0_beta too, and the GENERIC kernel of it is 7.4 MB with an additional 3.5 MB of LKM’s (cd9660, ntfs, compat_linux, ext2fs, smbfs and more), so that adds up to 11 MB.
That wouldn’t be a kernel meant for debugging would it? (I haven’t tried NetBSD 2.x yet, so I don’t know)
I run NetBSD 2.0_beta too, and the GENERIC kernel of it is 7.4 MB with an additional 3.5 MB of LKM’s (cd9660, ntfs, compat_linux, ext2fs, smbfs and more), so that adds up to 11 MB.
GENERIC contains all those modules. Those LKMs are provided for… Well, there must be a reason.
Quentin Garnier.
“I run NetBSD 2.0_beta too, and the GENERIC kernel of it is 7.4 MB with an additional 3.5 MB of LKM’s (cd9660, ntfs, compat_linux, ext2fs, smbfs and more), so that adds up to 11 MB.”
That wouldn’t be a kernel meant for debugging would it? (I haven’t tried NetBSD 2.x yet, so I don’t know)
Well, then I’ll strip the kernel. I don’t know if there are other debug things that can be in the kernel, though.
daang: {1} cp /netbsd .
daang: {2} ls -l netbsd
-rwxr-xr-x 1 daan users 7480711 Jun 3 15:08 netbsd
daang: {3} strip netbsd
daang: {4} ls -l netbsd
-rwxr-xr-x 1 daan users 6788268 Jun 3 15:08 netbsd
————————-
GENERIC contains all those modules. Those LKMs are provided for… Well, there must be a reason.
When I try to modload them, it complains about duplicate symbols, so they are indeed in GENERIC, and they can’t be loaded by a GENERIC kernel. Maybe they could be removed, but the NetBSD people haven’t yet? It’s still a beta snapshot, so things might not have a reason, I think.
NetBSD and OpenBSD forked like 8 years ago…
FWIW, my FreeBSD kernel size is 2,714,433 bytes and du -h /modules gives 5.7M – half of which are certainly not used…