什么是宏内核、微内核？

操作系统和普通的大型应用程序项目类似，都涉及代码组织方式的问题，但操作系统的独特之处在于其核心部分必须运行在内核态，kernel model，所谓内核态严格讲是指在该状态下程序拥有对硬件(hardware)的所有控制权，运行在用户态的程序做不到这一点。

有的同学可能会有疑问，操作系统(或者说内核)不都是核心部分吗？严格来讲像进程管理调度、内存管理等就是核心部分，但像驱动等就不是那么核心了，那么这一部分也需要放在内核态吗？

围绕这一划分，出现了两种操作系统的设计方式，关于这两种设计方法的争论就和复杂指令集(CISC)与精简指令集(RISC)哪个更好一样至今 没有非常明确的定论 。

大一统，全部运行在内核态

最简单的划分就是没有划分 ，我们可以把所有内核代码放在内核态，内核中的任何代码都拥有控制硬件的全部特权，显然这种设计方法非常简单，因为操作系统设计者不用费心去想哪一部分该放在内核态。

由于全部内核程序都运行在内核态，编译好的内核程序就是一个单独的二进制可执行文件，这时的操作系统运行起来后就是一个大进程，所有内核代码运行在一个单独的地址空间中，这和我们实现的稍微复杂的单进程应用程序类似，这种大一统的设计就是所谓的宏内核，monolithic kernel，个人认为叫“一体化内核”更形象些。

这种组织方式和TCP/IP协议栈的分层实现有点类似。

现在内核代码已经组织好了，毕竟内核是为上层应用提供服务的，那么上层应用该怎样调用内核代码呢？这就是系统调用的作用，system call。

上层应用程序通过系统调用与内核进行交互。

由于内核代码唯一同一个地址空间中，因此内核中各部分的交互极为简单，就是普通的函数调用，文件系统中的某块cache可以非常容易的被虚拟内存系统共享使用。

但宏内核也是有缺点的，由于内核代码位于同一个地址空间，代码趋于复杂化，复杂就容易出错，但内核和普通程序不同，一旦内核中某一模块出现bug将导致整个内核崩溃，底层的内核崩溃后上层的应用程序就无法继续正常推进。

当然也有人不在乎在这一点，Linus认为内核中有bug正常， 有bug就找到它、修复它而不是用某种机制试图忽略它 ，没错，C++中的异常就是试图忽略bug的机制，这就是为什么很多公司的规范中禁止使用异常的原因。

总之，内核崩溃后就必须重启计算机。

保留核心，非必要不留在内核

为减少内核崩溃的风险，一个简单的办法就是让内核尽量精简，只保留核心部分运行在内核态，其它代码以用户态进程的形式运行，就像这样：

运行在用户态的操作系统程序被称为server，像负责文件操作的File Server等，此时用户进程想要使用操作系统提供的服务的话就必须借助进程间通信，inter-process communication，即IPC，借助内核，消息从一个进程发送到另一个进程然后等待返回。

这样，内核只需要对上层应用提供一些简单的接口即可，像创建进程、发送消息等，这种实现方式可以让内核尽可能简单，因为大部分内核程序都运行在用户态，且运行在不同的地址空间中，此时设备驱动中的bug不会影响到内核，这种操作系统的实现方式就被称为微内核， micro kernel。

就像宏内核那样，微内核也有自己的缺点，那就是性能。由于宏内核的代码都在同一个地址空间中，因此模块间的交互可以非常简单，简单的函数调用即可，但模块间交互对微内核来说则可能涉及进程间通信，看上图，如果某个应用程序需要请求使用File Server，这条链路涉及到：

请求：应用程序 -> 内核 -> File server
返回：Filer server -> 内核 -> 应用程序

每一个"->"都涉及上下文切换，而这对宏内核来说则简单很多。

现实中是什么样子？

现实的操作系统中两种实现方式都很常见，Linux以及许多Unix就是典型的宏内核，而Mac OS X 以及 Windows NT则一般认为是微内核，华为的鸿蒙Harmony OS则宣传是微内核。

有趣的是，对Linus创建Linux影响极大的MINIX操作系统也是微内核，而Linux则是宏内核，难怪MINIX的作者——也是操作系统这门课的教授说过，如果Linus是他的学生的话那么操作系统系统这门课的期末考试Linus可能很难通过，哈哈，因为MINX的作者认为在Linux被创造出来的上世纪90年代竟然还有人以宏内核的方式来编写操作系统，这简直不可思议，而Linus则不以为意，并进行了火爆的回击，关于这一段的八卦后续有机会和大家聊聊，非常有趣。

可以看到操作系统的设计方式就和CPU关于复杂指令集与精简指令集的设计一样分成了两派， 关于宏内核与微内核孰优孰劣争论至今依然没有定论 。