典型操作系统内核架构
在典型操作系统架构（如下图所示）中，内核负责以安全、公平的方式为多个应用程序管理和共享硬件资源。
- 内核通过一组 API（即系统调用）向应用程序提供服务。这些 API 不同于常规库函数，因其是用户模式到内核模式切换的边界。
- 为保证应用兼容性，系统调用极少更改（Linux 尤其严格遵循此原则，而内核内部 API 可按需调整）。
内核代码可逻辑划分为两部分：
- 核心内核代码：通用功能，可进一步分为多个子系统（如文件访问、网络、进程管理等）。
- 设备驱动代码：负责与特定设备交互。
宏内核（Monolithic Kernel）
宏内核的特征是各子系统间无访问保护，公共函数可直接跨子系统调用。然而，大多数宏内核仍会在逻辑上隔离子系统：
- 核心内核与设备驱动之间通过相对严格（但非绝对固定）的 API 交互；
- 具体实现取决于内核架构（例如 Linux 通过模块化设计平衡灵活性与隔离性）。
微内核（Micro-Kernel）
微内核将大部分功能以用户空间服务形式运行，仅保留极小代码于内核模式（如调度器、IPC 机制和基础内存管理）。其特点包括：
- 服务隔离：服务崩溃可单独重启（理论上），但因依赖关系复杂（如文件服务崩溃会影响依赖其的应用程序），实际效果受限；
- 模块化与内存保护：服务间通过 IPC 通信，牺牲性能换取安全性；
- 性能代价：原本宏内核中的函数调用需转为 IPC 通信，引入额外开销；
微内核的支持者常认为其优势在于强制的模块化设计。然而，宏内核同样可以实现模块化，现代宏内核通过以下方式实现这一目标：
- 编译时启用/禁用组件
- 支持可加载内核模块（运行时动态加载）
- 将内核划分为逻辑独立的子系统
- 严格接口设计但低性能开销（如宏、内联函数、函数指针）
部分操作系统曾自称为“混合内核”（如 Windows、Mac OS X），声称介于宏内核与微内核之间。但由于其所有典型宏内核服务仍运行于内核模式，实际仍应归类为宏内核。许多操作系统专家认为“混合内核”仅是营销术语，缺乏实质意义。Linus Torvalds 对此评价：
“所谓‘混合内核’只是营销话术——不过是蹭微内核的公关优势，给现有内核贴个酷炫标签罢了。”