Core API 与基础设施
这页讲内核里的“公共工具箱”：很多模块看起来各干各的，但它们大量共享同一批基础设施。学这页的重点，不是背 API 名字，而是建立“为什么大家都在复用这层底座”的感觉。
这块是什么
Core API 可以理解成“内核内部最常复用的公共能力集合”。它不像网络、文件系统那样直接对最终用户可见，但许多模块都站在它提供的抽象和工具之上。如果缺少这层，很多子系统就得重复解决相同的基础问题。
如果把 Linux 内核看成一座城市，Core API 更像道路、管道、电网和通用设施，而不是某一个具体商店。
它通常包含什么
异步与后台执行
- workqueue
- 延后处理
- 后台工作调度
- 把工作放到更合适上下文里完成
通用容器与工具
- 链表、红黑树、xarray
- 通用辅助函数
- 日志与打印
- 减少各子系统重复造轮子
为什么内核需要这层公共底座
| 问题 | 如果没有公共底座会怎样 | Core API 的价值 |
|---|
| 对象怎么被安全释放 | 每个子系统自己设计规则，容易不一致，也容易埋内存和生命周期问题。 | 把“对象何时还能用、何时应释放”这类共性问题做成统一做法。 |
| 某些工作不能立即做完 | 各模块自己随意处理延后工作，会造成上下文混乱。 | 提供 workqueue 等机制，把延后执行这件事做得更规范。 |
| 数据结构如何高效管理 | 每个模块重复发明容器，学习成本和维护成本都会升高。 | 提供稳定、常见、可复用的数据组织方式。 |
| 日志和调试怎么统一 | 子系统之间输出风格混乱，排错成本高。 | 让基本日志输出和很多辅助能力有共同语言。 |
关键概念
| 概念 | 现在怎么理解 |
|---|
| kobject | 内核里一种很重要的“对象被系统统一看见”的方式，和 sysfs、设备模型等关系密切。 |
| kref | 引用计数工具，用来安全管理对象什么时候还能用、什么时候该释放。 |
| workqueue | 把某些工作延后到更合适的上下文里执行，而不是立刻硬做完。 |
| printk | 内核里最基础的日志输出机制。 |
| xarray / rbtree | 常见的内核数据组织工具，用来高效管理索引和查找。 |
你以后会在哪些地方反复遇到它
- 驱动和设备模型里，经常会碰到对象生命周期、引用计数和 sysfs 关系。
- 网络、文件系统、内存管理这类大子系统里，会不断看到链表、树结构、异步工作等公共设施。
- 很多看起来“像业务逻辑”的代码，底下其实只是把这些公共设施拼起来使用。
为什么重要
- 因为它降低了各个子系统重复造轮子的成本。
- 因为它把常见问题抽象成统一工具，帮助内核保持一致性。
- 因为很多你以后遇到的“陌生结构”其实不是某个子系统的特殊逻辑，而是公共基础设施。
常见误解
- 误解一：Core API 只是一些零碎小工具。实际上它承担的是“统一内核公共做法”的职责。
- 误解二：只学具体子系统就够了，不用学这层。实际上不理解这层，读很多模块都会一直卡在共性机制上。
- 误解三：看到容器、引用计数、workqueue 就是细节。其实它们恰恰是内核整体组织方式的一部分。
它负责什么 / 不负责什么
| 负责什么 | 不负责什么 |
|---|
| 提供可复用的底层机制和工具。 | 不直接决定网络协议怎么处理、文件如何存盘、驱动如何和具体硬件交互。 |
| 统一很多基础问题的做法。 | 不等于单独系统功能模块。 |
| 让其他子系统少重复解决公共问题。 | 不替代具体子系统自身的核心职责。 |
和其他模块的关系
- 和驱动：驱动模型、对象生命周期、日志、异步工作都常借用它。
- 和内存管理：很多基础容器和对象都需要和内存分配配合。
- 和并发：公共基础设施常常要和锁、RCU、原子操作一起使用。
- 和文件系统/网络：这些大子系统虽然复杂，但底层仍会复用大量通用工具。
读完这页后，你应该能回答
- 为什么很多完全不同的子系统会共享同一批基础工具？
- 为什么 workqueue、kref、xarray 这种名字在很多地方都反复出现？
- 为什么 Core API 不是“边角料”，而是整个内核的公共底座？
后面适合继续问：kobject 为什么对设备模型很关键？workqueue 和中断上下文是什么关系？引用计数为什么比表面看起来更重要？