我读到 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 微内核。我无意贬低其他人最近的工作。
