2. 内核版本演进与API变化
Linux内核的版本号规则、API差异以及LTS与主线版本的选择策略，是驱动移植适配工程中最基础的决策依据。理解版本号的语义、掌握主要版本间的API变化规律、并根据产品生命周期合理选择内核基线，能够显著降低移植成本与长期维护风险。
2.1 Linux内核版本号规则
自2.6内核起，Linux采用主版本.次版本.补丁级别的三段式版本号，并在2020年后引入主版本.次版本.补丁级别-rcN的预发布标记。版本号本身不再直接标识稳定版或开发版，而是通过发布流程与维护状态区分。
| 版本段 | 示例 | 含义 | 变更频率 |
|---|---|---|---|
| 主版本 | 5 | 重大架构变化、API不兼容 | 约2~3年 |
| 次版本 | 10 | 新特性、驱动API扩展 | 约2~3个月 |
| 补丁级别 | 120 | 安全修复、bug修复、无新API | 每周~每月 |
| 预发布标记 | -rc5 | 候选发布版本，用于测试 | 每个合并窗口后 |
版本号判断要点：驱动移植时，应关注次版本号的变化。次版本号每增加1，通常意味着合并窗口期间有大量驱动API更新。补丁级别变化一般不影响驱动接口，可直接应用。
2.2 主要版本间的API差异
内核版本演进过程中，驱动开发者最常遇到的API变化集中在以下几个子系统。下表列出了从4.x到6.x主要版本间的典型差异。
| 子系统 | 4.x (典型4.19) | 5.x (典型5.10) | 6.x (典型6.1) | 迁移注意事项 |
|---|---|---|---|---|
| 设备树(DT) | of_* API为主 | 引入device_property_* API | of_*逐步弃用，推荐通用属性API | 优先使用device_property_read_*系列 |
| GPIO子系统 | gpio_* 整数接口 | gpiod_* 描述符接口 | 旧整数接口完全移除 | 必须迁移到gpiod_* API |
| 时钟框架 | clk_prepare_enable | clk_bulk_* 批量操作 | clk_hw_* 硬件抽象层 | 批量操作可简化多时钟驱动 |
| 中断子系统 | request_irq | request_threaded_irq | 引入irq_domain_ops扩展 | 线程化中断成为标准模式 |
| DMA引擎 | dma_async_* | dmaengine_* 统一接口 | 新增dma_buf同步机制 | 注意dmaengine_prep_*函数签名变化 |
| regmap | regmap_write/read | regmap_bulk_* 批量接口 | regmap_field_* 位域操作 | 位域操作可减少掩码计算 |
| 时间子系统 | do_gettimeofday | ktime_get_* 系列 | ktime_get_ns等纳秒接口 | 废弃do_gettimeofday，使用ktime系列 |
常见陷阱：许多驱动在4.x到5.x迁移时，只修改了函数名而未修改语义。例如
gpio_request改为gpiod_get后，返回值类型从int变为struct gpio_desc *，错误处理逻辑必须同步调整。
2.3 LTS版本与主线版本的选择策略
LTS（长期支持）版本与主线版本的选择直接影响驱动移植的工作量和产品维护周期。下图展示了不同内核版本类型的生命周期与适用场景。
2.4 LTS版本生命周期与维护策略
当前活跃的LTS版本及其维护周期如下表所示。驱动移植时，应优先选择维护周期覆盖产品生命周期的LTS版本。
| LTS版本 | 发布年份 | 初始维护期 | 延长维护期 | 当前状态 |
|---|---|---|---|---|
| 4.19 | 2018 | 2年 | 6年 | 维护中（至2024年12月） |
| 5.10 | 2020 | 2年 | 6年 | 维护中（至2026年12月） |
| 5.15 | 2021 | 2年 | 6年 | 维护中（至2027年10月） |
| 6.1 | 2022 | 2年 | 6年 | 维护中（至2028年12月） |
| 6.6 | 2023 | 2年 | 6年 | 维护中（至2029年12月） |
实践建议：对于2024年启动的新产品，推荐以6.1或6.6 LTS作为基线。这两个版本在驱动API上已经稳定，且社区支持活跃。避免使用即将结束维护的4.19或5.10版本，除非产品已有大量遗留代码。
2.5 主线版本与LTS版本的API差异管理
主线版本每2~3个月发布一次，API变化频繁。LTS版本则冻结API，只向后移植安全修复。驱动移植时，需要关注以下差异管理策略：
- API版本检测：使用
LINUX_VERSION_CODE和KERNEL_VERSION宏进行条件编译 - 兼容层封装：为差异较大的API编写内联兼容函数，避免大量#ifdef
- 特性门控：使用
CONFIG_*内核配置选项控制新特性代码 - 向后移植补丁：从主线提取关键API变更，反向移植到LTS版本
/* API版本检测示例 */
#include <linux/version.h>
#if LINUX_VERSION_CODE >= KERNEL_VERSION(5, 10, 0)
/* 使用新API */
struct gpio_desc *gpio = gpiod_get(dev, "reset", GPIOD_OUT_LOW);
#else
/* 使用旧API */
int gpio = of_get_named_gpio(dev->of_node, "reset-gpios", 0);
gpio_request(gpio, "reset");
gpio_direction_output(gpio, 0);
#endif
条件编译陷阱：过度使用
#if LINUX_VERSION_CODE会导致代码可读性急剧下降。建议将版本差异封装到独立的兼容头文件中，驱动主体代码只调用统一接口。
2.6 版本选择决策流程
在实际工程中，选择内核版本应遵循以下步骤：
- 评估产品生命周期：确定产品需要维护的年数（消费电子2~3年，工业5~7年，医疗10年+）
- 匹配LTS维护窗口：选择维护周期覆盖产品生命周期的LTS版本
- 检查硬件支持状态：确认所选内核版本包含目标SoC/外设的完整驱动支持
- 评估驱动移植工作量：对比当前驱动与目标内核版本的API差异，估算修改量
- 社区活跃度检查：查看LKML和对应子系统邮件列表的讨论活跃度
- 安全补丁覆盖：确认LTS版本是否被CVE跟踪系统覆盖
通过系统化的版本选择与API差异管理，驱动移植工作可以从被动应对变为主动规划，显著降低长期维护成本。