【Linux】对比直接编译进内核和模块形式

Compiling directly into a kernel vs. modules

You have two options for adding functionality to the kernel: building functions into the kernel (making a monolithic kernel) or adding them as modules. 

Monolithic kernels: 
Building a function into the kernel directly ensures that that function will be available at all times. The downside is that it makes your kernel bigger, increasing boot time, and ultimately using that much more memory to hold the kernel. If you are compiling a kernel to fit on a floppy so that you can boot Linux off a rescue floppy, space will become an issue. 


Modules: 
Building a function as a module allows that function to be loaded into memory as needed and unloaded when it is no longer needed. This helps keep your kernel small. It is very useful if, say, you are swapping hardware in and out of your system frequently. You could compile support for a variety of, say, sound cards as modules, and your Linux system will theoretically only load the driver that is appropriate for the hardware setup at the time. 


Another benefit of building functions as modules is that parameters can be passed to the modules which can be useful in debugging your system if problems occur. 


There are some considerations to be made when deciding if a kernel function should be modularized. A small performance penalty is paid as it takes a little time to get the module loaded and unloaded. There are some functions that are needed at boot time and these cannot be compiled as modules -- they need to be present in the kernel so your system can be loaded. For example, ext2/ext3/reiserfs file system support needs to be built into the kernel so that your partitions can be read, as you need to be able to read the filesystem to load modules. In my case, if I have PCMCIA support built into the kernel, then metworking works. If PCMCIA support is modularized, networking fails to start, probably because the PCMCIA support needs to be available very early in the boot process to set up networking. 


General approach 

The way that I approached kernel building was to see which functions I would need all the time versus the ones that I would only use infrequently. If it was a function that I would be using a lot, I built it directly into the kernel. Otherwise, I compiled it as a module. As I got more comfortable with recompiling the kernel, I started making more functions as modules, and honestly, have not seen that much change in system performance. On the other hand, my hardware setup is pretty static -- my machine is a laptop, and the only hardware option that I have is whether or not I have a USB mouse plugged into it. 

你有两个方法将功能加载到内核：直接将功能内建在内核使他变成内核的一部分或者以模块形式加入。


内建形式：


将功能内建在内核里可以确保此功能永远都开启。但缺点就是增加你内核的“体积”从而拖慢了你开启引导的时间， 并且这个“变大”的内核需要更多的内存。如果你是打算将内核编译到软盘， 从急救软盘开启引导的话， 空间将成为一个不容忽视的问题。


模块形式：


将功能编成模块可以让此功能在需要的时候加载在内存里而不需要的时候可以卸载，这样， 你的内核可以保持一个比较小的“体积”。 如果你是经常将硬件“交换”（swap in and out)进出的话， 这个方式是很有用的。你可以将很多支持的硬件编成模块形式比如你的声卡， 这样理论上系统会将此驱动正常的在硬件安装的时候挂载上去。


另一个编成模块形式的优点就是当你要在系统出错的时候， 模块形式可以允许你加入你自己的参数， 从而使得出错工作简单化。


当你要编成模块形式的时候几个问题要考虑进去。 首先是考虑到加载和卸载模块的时间， 当然这个问题并不是很严重。有一些功能是需要在开机引导的时候就要的而他们是不可以编成模块形式。当系统被加入在内存后， 这些功能就必须要加载了。比如支持ext2/ext3/reiserfs的功能是需要内建在内核里的这样你的分区才能被系统读到。另外我还有一个例子， 我有一个PCMCIA的网卡， 如果我将PCMCIA编入到内核使他可以在开机引导的时候就正确挂载的话， 我的网路可以启动运作， 但相反如果我用模块形式的话， 网路无法正确启动， 这是因为PCMCIA是需要在刚启动系统的时候就要挂载上去的原因。


一般编译方案：
我判断是否要将功能编成内建形式是判断此功能是否是我一直都需要并且是否我经常在用。如果这个功能我平时用的很多的话， 我会直接讲它编到内核里， 不然就变成模块。再我不断的重新编译内核的时候， 我开始将许多功能转成模块， 老实说， 我没有觉得这样会让系统效率下降。另一方面， 我的硬件功能也不多， 就是一个笔记本电脑， 唯一的硬件选择项目就是我要不要将USB的滑鼠插到系统上。