为什么我们不能在操作系统的内核中添加最大的功能？

我认为理解这个问题的一个微妙但重要的方面取决于术语“可靠”和“有效”的定义。对于此答案，我将使用以下常规定义：

• 可靠：困难或不太可能发生故障或以其他方式破裂/崩溃

• 高效：即使以牺牲空间为代价，也需要最少的时间来完成某些任务

虽然并非每个人都以相同的方式定义术语（例如，在嵌入式系统中，使用最少的空间可能被认为更“有效”），但在大多数情况下，我认为用户倾向于偏向于速度。

微内核背后的想法是在内核中提供最小的功能，以使其可靠和高效。

我认为这里的重要部分是“最小功能”。具有最少数量的功能意味着必须编写，读取和维护/调试的代码数量少于其中包含更多内容的代码数量。

从这个意义上讲，考虑到我上面的定义，更少的代码意味着内核的整体更小，可能更简单并且更易于使用。系统越简单，就越容易发现潜在的/实际的问题，从这个意义上说，该系统更加“可靠”。这减少了将新的隐藏错误纳入代码库并在以后破坏某些内容的机会。

它还可以使它更“有效”（即更快），因为系统将需要较少的开销处理来保持自身正常运行。换句话说：您要做的工作越少，花在工作上的时间就越少。

打个比方，假设您正在读书。完成本书所需阅读的页面越少，故事情节就越容易理解，完成本书的速度也就越快。

这是否意味着“具有最大功能的内核”将不会可靠且高效？

尽管这取决于“最大功能”的含义，但不一定。例如，在内核中安装媒体播放器，电子邮件客户端和文字处理器是否可以帮助它实现“最大功能”？也许。是否有意义？不。

在此讨论中，我将使用以下定义：

• 最大的功能：与最大数量的硬件兼容

实际上，这意味着如果要将某些组件A交换为某些其他组件B（即网卡），则计算机应继续正常运行，而不是拒绝引导。

从这个意义上讲，内核可以具有“最大功能性”而不会完全牺牲“效率和可靠性”。

为了使内核能够识别组件，加载驱动程序等，需要添加代码，这将增加编写代码时引入错误的几率以及需要处理的处理开销。增加的功能。即使那样，大多数错误也只是暂时的。

因此，如您所见，这是一个折衷方案。那么，微内核呢？

微内核专门通过将不太重要的“服务”推送到内核外部来管理这种折衷……这反过来意味着通常可以使内核崩溃的事物（例如错误的驱动程序） ，因此整个机器也会被推到外面。如果行为不当，这会限制它们可能造成的破坏数量。

一旦进入内核之外，它们将作为用户空间应用程序（例如，类似于记事本）而不是内核空间（例如，单片内核中的图形卡驱动程序）运行，并且如果这些服务或应用程序中的任何一个有问题且崩溃，则机器本身更有可能生存下来，而不是显示BSoD或同等功能。

例如，如果文本编辑器崩溃，则仅该应用程序关闭。如果在内核空间中运行的图形卡驱动程序崩溃，则可能需要重新启动。

但是正如我提到的，这是一个权衡。例如，将内核功能迁移到用户区域确实会带来一些效率/速度方面的损失。过去在内核空间中同一进程内的单片内核（例如Linux）中曾经是一个简单的函数调用，现在需要处理进程间通信与自身之外的多个独立任务的开销，这需要在它们之间进行更多的上下文切换和时间，才能完成任务。

打个比方，假设您正在读一本书，其中有多个角色会在故事的关键点做出重要决策，但是这本主要书籍仅着眼于主要角色，这些决策对辅助角色的影响将单独处理。附带故事的书籍。主书本身将更短，更简单，但是您必须不断地在各书之间进行切换以实际阅读所有内容，这意味着您将花费更多的时间来完成它。

希望这可以帮助。