Skip to main content
 首页 » 编程设计

architecture之为什么Linux被称为单片内核

2024年02月24日8三少

我读到 Linux 是一个整体内核。整体内核是否意味着将完整的内核代码编译并链接到可执行文件中?

如果Linux能够支持模块,为什么不将所有子系统分解为模块并在需要时加载它们呢?在这种情况下,内核不必首先加载所有模块,并且可以维护模块中函数的索引并在需要时加载它们。

请您参考如下方法:

单片内核是这样一种内核,其中所有服务(文件系统、VFS、设备驱动程序等)以及核心功能(调度、内存分配等)都是共享同一空间的紧密结合的组。这直接反对微内核

微内核更喜欢将核心功能与系统服务和设备驱动程序(基本上只是系统服务)隔离的方法。例如,VFS(虚拟文件系统)和 block 设备文件系统(即 minixfs)是在内核空间之外运行的独立进程,使用 IPC 与内核、其他服务和用户进程进行通信。简而言之,如果它是Linux中的模块,那么它就是微内核中的服务,表示一个隔离的进程。

不要将术语模块化内核与整体内核混淆。一些整体内核可以编译为模块化(例如Linux),重要的是模块被插入到处理核心功能的同一空间(内核空间)并从中运行。

微内核的优点是任何失败的服务都可以轻松重新启动,例如,如果根文件系统抛出中止,则内核不会停止。不过,这也可以被视为一个缺点,因为它可以隐藏非常关键的错误(或者使它们看起来不那么关键,因为问题似乎会不断自行修复)。在部署后您无法方便地修复某些内容的情况下,它被视为一个很大的优势。

微内核的缺点是异步 IPC 消息传递可能会变得非常难以调试,尤其是在 fibrils 的情况下。已实现。此外,仅仅追踪 FS/写入问题就意味着检查用户空间进程、 block 设备服务、VFS 服务、文件系统服务和(可能的)PCI 服务。如果您对此一无所知,那么就该看看 IPC 服务了。这在整体内核中通常更容易。 GNU Hurd遭受这些调试问题( reference )。在处理复杂的消息队列时,我什至不打算讨论检查点。微内核不适合胆小的人。

通向工作、稳定内核的最短路径是整体方法。任何一种方法都可以提供 POSIX 接口(interface),对于那些只想编写在任何给定设计上运行的代码的人来说,内核的设计变得没什么兴趣。

我在生产中使用 Linux(整体)。然而,我对内核开发的大部分学习、黑客或修补都进入了微内核,特别是 HelenOS .

编辑

如果您通过我冗长的回答读到这里,您可能会在阅读“Great Torvalds-Tanenbaum debate on kernel design”时获得一些乐趣。 '。 2013 年,也就是这件事发生 20 多年之后,再读起来就更有趣了。最有趣的部分是 Linus 在最后一条消息中的签名:

Linus "my first, and hopefully last flamefest" Torvalds 

显然,这就像 Tanenbaum 预测 x86 很快就会过时一样,并没有成为现实。

注意:

当我说“Minix”时,我并不是指 Minix 3。此外,当我提到 HURD 时,我指的是(主要)Mach 微内核。我无意贬低其他人最近的工作。