1. 课程导论与背景：Linux 4.x 到 6.x 内核演进概述
1.1 内核版本演进时间线与关键里程碑
Linux 内核从 4.0（2015 年发布）到 6.x（2023 年起稳定）经历了近十年的高速迭代。这期间内核在调度器、内存管理、文件系统、网络协议栈以及驱动框架层面发生了根本性变革。理解版本演进的时间线，是评估移植工作量的第一步。
| 主版本 | 首发年份 | 关键特性 / 驱动相关变更 |
|---|---|---|
| 4.0 – 4.9 | 2015 – 2016 | 引入 livepatch；dmaengine 框架重构；pinctrl 子系统成熟；regmap 广泛采用 |
| 4.10 – 4.19 | 2017 – 2018 | drm 图形驱动框架大改；IIO 工业 I/O 子系统标准化；clk 框架引入 clk_hw 结构体 |
| 5.0 – 5.10 | 2019 – 2020 | gpio 子系统弃用整数 API；pwm 框架引入原子操作；i2c 与 spi 设备树绑定规范化 |
| 5.11 – 5.19 | 2021 – 2022 | usb 驱动迁移至 usb_role；phy 子系统引入 phy_ops 回调；interrupt 子系统弃用 IRQF_NO_SUSPEND 旧语义 |
| 6.0 – 6.6+ | 2023 – 2024 | regulator 框架强制 devm_ 管理；dma_buf 同步机制重写；pinctrl 状态切换接口变更；clk 框架移除旧版 clk_register |
移植视角： 版本跨度越大，API 语义变化越剧烈。从 4.x 直接跳到 6.x，相当于跨越了 3 次重大内部 API 重构周期，不能仅靠“搜索替换”完成。
1.2 驱动 API 重大变更概览
驱动开发者最直观的感受是：大量“遗留”API 被标记为 __deprecated 或直接移除。以下列出 4.x 到 6.x 之间影响面最广的几类变更。
- 设备管理模型：
device_register()与device_create()的返回值和错误处理语义调整；devm_系列 API 成为强制标准。 - 时钟框架：
clk_get()/clk_enable()被clk_bulk_get()/clk_bulk_enable()替代；struct clk不再直接暴露寄存器操作。 - GPIO 子系统： 整数 GPIO 编号 API（
gpio_request()、gpio_direction_output()）在 5.0 后彻底移除，必须使用gpiod_描述符 API。 - 中断子系统：
request_irq()的IRQF_SHARED行为收紧；devm_request_irq()成为推荐方式；线程化中断要求更严格的IRQF_ONESHOT处理。 - DMA 引擎：
dmaengine_slave_config()的struct dma_slave_config新增peripheral_config字段；dma_async_issue_pending()语义变更。 - Regmap / Regulator：
regmap_write()缓存机制默认启用；regulator_set_voltage()增加快速切换标志。
核心原则： 6.x 内核强制驱动使用“资源管理”版本 API（
devm_ 前缀），不再允许手动 kfree() / iounmap() 配对。所有旧版手动释放代码必须重构。
1.3 移植适配的必要性与挑战
为什么必须从 4.x 升级到 6.x？因为长期维护的 4.x 分支（如 4.19 LTS）已在 2024 年底停止安全更新。继续使用意味着暴露在已知 CVE 漏洞中，且无法利用新硬件（如 PCIe Gen5、USB4、CXL 内存）的驱动支持。
移植适配面临的主要挑战包括：
- API 语义不兼容： 同名函数可能参数类型、返回值含义、错误码已改变。
- 设备树绑定变更： 6.x 内核强制使用
YAML格式绑定文档，且compatible字符串匹配规则更严格。 - Kconfig 依赖变化： 大量内核配置选项被合并、重命名或拆分，导致
defconfig无法直接使用。 - 休眠/唤醒流程重构：
suspend/resume回调的调用顺序和PM域管理逻辑在 5.10 后发生根本变化。 - 并发模型升级： 自旋锁、mutex、RCU 的使用规则收紧，旧驱动中不规范的锁操作在 6.x 下可能触发
lockdep警告或死锁。
常见误区： 不要认为“编译通过就等于移植完成”。6.x 内核的
__init / __exit 节区检查更严格，运行时行为（如 probe 顺序、DMA 缓存一致性）可能与 4.x 完全不同。必须进行完整的功能回归测试。
1.4 内核驱动框架演进全景图
下图展示了从 4.x 到 6.x 内核中，主要驱动子系统框架的演进路径与关键节点。每个子系统都经历了至少一次内部 API 重构或接口标准化。
1.5 移植适配的典型工作流
一个完整的驱动移植适配项目通常包含以下阶段。每个阶段都有明确的交付物和检查点。
| 阶段 | 主要活动 | 典型耗时 | 风险等级 |
|---|---|---|---|
| 1. 基线分析 | 梳理驱动依赖的内核 API、Kconfig、设备树绑定 | 1 – 2 天 | 低 |
| 2. API 映射 | 逐函数对比 4.x 与 6.x 接口差异，建立映射表 | 2 – 3 天 | 中 |
| 3. 代码重构 | 替换 API、调整锁/PM 逻辑、更新设备树 | 3 – 5 天 | 高 |
| 4. 编译适配 | 解决编译错误、处理 Kconfig 依赖、修复头文件路径 | 1 – 2 天 | 中 |
| 5. 功能验证 | 在目标硬件上运行驱动，测试基本 I/O、中断、休眠唤醒 | 3 – 5 天 | 高 |
| 6. 压力测试 | 长时间运行、并发访问、边界条件测试 | 2 – 3 天 | 中 |
经验数据： 一个中等复杂度（约 3000 行代码）的字符设备驱动，从 4.19 移植到 6.6，平均需要 10 – 15 个工作日。其中 API 映射和锁/PM 重构占 60% 的工作量。
1.6 课程学习路径与预期收获
本课程将按照“基础概念 → API 变更详解 → 实战案例 → 调试与验证”的路径展开。每章都会提供可编译的示例代码和移植前后对比。
- 第 2 – 5 章： 深入讲解设备模型、时钟、GPIO、中断子系统的 API 变更细节。
- 第 6 – 10 章： 覆盖 DMA、Regmap、Regulator、Pinctrl、IIO 等子系统的移植要点。
- 第 11 – 15 章： 实战案例：I2C 触摸屏驱动、SPI 传感器驱动、USB 设备驱动从 4.x 移植到 6.x。
- 第 16 – 20 章： 设备树绑定升级、Kconfig 重构、PM 域适配。
- 第 21 – 25 章： 调试工具（ftrace、lockdep、devmem2）在移植中的应用。
- 第 26 – 30 章： 完整项目实战：将一款 4.19 下的多媒体编解码器驱动移植到 6.6 内核。
学习建议： 准备一台运行 6.x 内核的开发板（如 Raspberry Pi 5 或 BeagleBone Black），并搭建 4.19 与 6.6 双内核编译环境。所有示例代码都将在两个版本上对比验证。