查看“Modular Kernel”的源代码

{{Template:Kernel designs}}

模块化内核是一种合并内核级驱动程序和第三方驱动程序优点的尝试。 在模块化内核中，系统核心的某些部分将位于称为 “模块” 的独立文件中，这些文件可以在运行时添加到系统中。 根据这些模块的内容，目标可能会有所不同，例如:
* 仅在实际找到设备时才加载驱动程序
* 仅在实际请求时加载文件系统
* 仅在应评估特定 (调度/安全/任何) 策略时加载代码
* 等等。

然而，基本目标保持不变: 将启动时加载的内容保持在最低限度，同时仍允许内核执行更复杂的功能。 模块化内核的基础非常接近我们在应用程序或 “动态库” 中实现 “插件” 时发现的内容。

== 模块化内核有哪些优缺点 ？==
=== 优势 ===
* 内核不必在启动时加载所有内容; 可以根据需要进行扩展。 这可能会减少启动时间，因为除非使用它们运行的硬件，否则某些驱动程序不会被加载 (注意: 根据模块是什么驱动程序，如何加载它们等，此启动时间减少可以忽略不计。)
* 核心内核没有那么大
* 如果需要新模块，则不必重新编译。

=== 缺点 ===
* 它可能会失去稳定性。 如果有一个模块做得不好，内核可能会崩溃，因为模块应该具有完全权限。
* ... 因此安全受到损害。 一个模块可以做任何事情，所以人们可以很容易地编写一个邪恶的模块来崩溃。 (某些OSs，例如 [https://en.wikipedia.org/wiki/Linux Linux]，仅允许root用户加载模块。)
* 编码可能会更加困难，因为该模块无法在没有内核符号的情况下引用内核过程。

== 模块化内核是什么样子 ？==

几乎每个模块化内核都可以识别几个组件:
; 核心
: 这是内核中绝对强制性的功能集合，无论你是否拥有模块。
;模块装载机
: 这是系统的一部分，将负责准备模块文件，以便可以像核心本身一样使用它。
;内核符号表
: 这包含有关模块加载程序需要的核心和已加载模块的其他信息，以便将新模块 “链接” 到现有内核。
;依赖项跟踪
: 一旦你想 “卸载” 某个模块，你就必须知道你是否能做到。 特别是，如果模块 “x” 已从模块 “z” 请求符号，则在系统中存在 “x” 时尝试卸载 “z” 可能会造成破坏。
;模块
:你可能想要 (或不希望) 拥有的系统的每个部分。

== 这样的系统如何首先启动？==

如果你仍然希望系统启动，则必须在一定范围内进行模块化。 将 “全部” 文件系统和设备驱动程序 (包括引导设备驱动程序) 推入模块可能会使引导时间更加复杂。 但是，可以使用以下解决方案:
* 内核提供了一个非常简单的 [[File Systems | 文件系统]] (例如SCO的 [[BFS]]) 驱动程序，并且该文件系统包含用于访问其余系统存储的模块 (例如ATA，SCSI，EXT2FS，[[ReiserFS]]，FAT，NTFS ...)。
* 内核随附带有其他存储模块的内置本机文件系统驱动程序，并且应使用该本机文件系统存储主要配置文件。 这是Linux遵循的方法，当一些人决定在任何地方使用 [[ReiserFS | reiser]] 时，ext2-fs只有内核开始在某些机器上出现问题。
* 引导加载程序知道它不仅应该加载 “内核”，还应该加载预配置模块的集合，因此内核只需要检查并初始化预加载的模块即可访问其他模块和主要配置文件。 这意味着你的引导加载程序充当自己的操作系统，例如 [[GRUB]]。

在这种情况下，ramdisk驱动程序和专用引导分区/保留扇区将是你的朋友。

== 另见 ==
=== 论坛主题 ===
*[[Topic:10031|Design of a basic module loader]]
*[[Topic:9921|Calling a function knowing its name]]
*[[Topic:9827|Ideas for IPC]]
*[[Topic:9742|Coff i386 relocations]]
*[[Topic:9713|Device Drivers Interface]]
*[[Topic:9437|Loading Drivers into Kernel]]
*[[Topic:9408|Design & Implementation of Extensible OS]]

[[Category:Kernel]]