微内核的结构

通用操作系统要满足各种不同用户的要求，因此对它在功能上的要求是“通用”，所以其功能是越多越好。而嵌入式操作系统就有所不同，因为嵌入式操作系统的用户群以及对功能的要求有某种程度的“专用”性，所以在一个特定的应用中，嵌入式操作系统需要哪些功能、不需要哪些功能基本上是固定的。因此，这就给设计小内核创造了条件。

相对于通用计算机系统而言，内存在嵌人式系统中是更为稀缺珍贵的资源。因此，作为需要常驻内存的操作系统的内核，在满足应用的前提下越小越好。

另外，为了满足不同的应用需要，嵌人式实时操作系统作为嵌人式系统重要的软件，应支持可裁剪性。换句话说，嵌人式实时操作系统的设计在结构上应高度模块化，并要提供非常灵活的手段，让系统开发者能根据实际需要进行选用。当然，也应允许用户根据需要编写自己的功能模块，并可以很方便地集成到系统中。

目前，从操作系统现有的结构来看，对于嵌入式实时操作系统来说，使用微内核结构应该是一个较好的选择。

在这里需要强调的是，微内核并不是通过减少内核的服务功能模块而变小的，而是把内核中应提供的部分服务功能模块移动到内核外来实现的。这一点看起来有些费解，其实也很简单。还是拿到饭店吃饭为例，如果你按菜单点的某道菜肴，等了一会儿，你可能是吃到了这道菜，你作为一个顾客享受了这道菜肴，但是这道菜真的是这个饭店做的吗?不一定，有可能就是其他饭店做的菜，只不过这个饭店在接收你的要求之后，它把消息发到另外一家饭店并让他们把菜做出来，再拿到你的餐桌上罢了。如果一个饭店的大部分菜肴都可以这样来提供，那么这个饭店所占用的土地面积一定会小得多。

其实，微内核的设计思想与上面所举的例子一样。如果把内核的某些服务模块作为一个进程放在内核以外，那么当要求服务的进程有服务要求时，这个仍然是通过系统调用接口向内核提出服务申请，而系统调用接口接收到该申请后，则立即通过向内核外的服务进程发送一个消息来启动这个服务进程，从而为要求服务的进程提供了相应的服务。显然，这样一来，就会使要求服务的进程和提供服务的进程都处在操作系统的用户区而处在同一个层次上了，所以内核也就变小了。为了区别两种不同的进程，把要求服务的进程叫做“客户”，把提供服务的进程叫做“服务器”，这种微内核结构也叫做“客户/服务器”结构。微内核的“客户/服务器”结构示意图如图所示。

图 微内核的客户/服务器结构示意图

在微内核中，由于客户/服务器的这种结构使内核变得更便于维护，一旦某部分发生错误，不会影响其他部分的工作，并且很适合嵌人式系统可裁剪性的要求：如果系统不需要某种服务，则只要简单地把相应的服务器删掉即可。当然，系统设计人员也可根据实际需要对某一服务器进程进行修改，雨不会影响其他部分，再由于内核是通过消息与服务器联系的，是动态链接的，因此在修改某个服务器进程后，只要对修改的服务器进行编译即可，而没有必要对整个操作系统进行编译。

此外，这种结构也适用于分布式系统。当客户需要远程服务器服务时，只要在系统调用的库函数中把客户进程的请求装配成数据包转发给远程的服务器，再接收远程服务器所返回的结果，把结果再返回给客户进程。对客户进程来说，它像正常一样使用系统调用，而不知道也没有必要知道这个服务是来自本地还是来自远程主机。

尽管可把原属于内核的服务模块移动到内核以外，但有几项基本服务是没有办法这样做的。例如，描述进程的进程控制块一定应该是内核的内容，于是与进程控制块相关的进程调度、进程创建、进程删除等需要访问进程控制块的服务必须要保留在内核中;进程通信的管理当然也要保留在内核中;中断的管理也要保留在内核中。总之，凡是需要使用处理器特权指令的功能模块都要保留在内核中。