操作系统一般分为宏内核与微内核两种。其中宏内核具有执行效率较高的特点，而微内核具有很好的可移植性。
宏内核中对于系统调用由于是直接调用相应服务的函数，不存在进程间通信及进程切换的开销，因此效率较高。但正由于各个模块之间的直接调用，导致模块之间出现了紧耦合，不利于模块之间的独立。虽然Linux已经移植到了现今绝大多数的平台之上，但仅从系统结构的角度来说，微内核无疑更好一点。
在微内核中，内核只需完成诸如系统启动、系统硬件检测、内存管理、进程管理、进程间通信的功能。其他的诸如鼠标处理、键盘处理、文件系统、GUI子系统则有不同的服务进程来实现。客户进程采用进程间通信的方式来请求服务进程完成相应的功能。
比如客户进程要读一个文件，则通过系统调用的方式给文件服务进程发送一个读取文件的请求消息。此时，客户进程则进入阻塞状态，内核发生任务调度。当调度到文件服务进程时，文件服务进程获得消息，从消息中取得适当的参数，完成实际的文件读取操作。然后，文件服务进程也采用系统调用的方式给客户进程发送一个消息。在这个发送消息的系统调用中，内核检测客户进程是否是因为等待当前消息而阻塞的，如果是就把客户进程唤醒。然后，内核即可返回服务进程或进行新的任务调度。
从以上的说明来看，微内核除了完成必要的工作外，其实只是一个消息的转发器，内核本身并不完成实际的工作，而是由相应的服务进程来完成的。因此移植的时候，只需要移植内核本身即可，而服务进程则不需要或只需进行很少的移植。这要看服务进程是否依赖于硬件而定。比如鼠标服务进程，首先鼠标中断肯定是在内核中响应的，然后内核会通过一定的方式来找到具体的处理鼠标中断的服务进程并将发生中断的消息发送给该服务进程。在这里就有两种处理方式。一：内核中的中断处理函数可以先从相应地端口读取数据并更新相应的记录鼠标状态的数据，然后直接附加在发送给服务进程的消息中，或者由服务进程通过系统调用的方式从内核读取。二：允许服务进程操纵端口，内核只发送发生中断的消息给服务进程即可。然后服务进程从相应的端口读取数据。这两种方式各有优劣，第一种把服务进程与具体的硬件分离，服务进程只依赖于内核，但增加了系统调用的开销，而且内核需要对不同的中断进行不同的处理，一来增加了内核的复杂度，二来也增加了内核与硬件的耦合度。而第二种方式则将服务进程与具体的硬件平台联系了起来，但这样可以自由的处理消息。内核只要通知服务进程发生了中断即可，服务进程可以自由处理中断而不必依赖于内核对特定消息的参数及其顺序的定义，也不必依赖于特定系统调用，而在系统调用及返回中肯定也伴随着对特定数据的结构定义。
宏内核与微内核各有优点，也各有缺点。但从系统结构及学习操作系统内核原理的角度来说，微内核无疑具有更大的优势。而且随着硬件的不断发展，微内核的性能问题必将退居次要的地位。而微内核的良好架构也特别适合模块化的开发，对于现今越来越复杂的软件开发来说，无疑将提供巨大的好处。