gfreewind/kernel_comment项目解析：Linux稳定内核补丁提交规则详解

什么是Linux稳定内核

Linux内核开发采用双轨制：主线内核（由Linus Torvalds维护）和稳定内核（-stable）。稳定内核专注于将已经进入主线内核的重要修复向后移植到已发布的稳定版本中，为用户提供安全、可靠的系统更新。

稳定内核补丁的准入标准

稳定内核补丁必须满足以下严格条件：

1. 正确性与测试要求

   • 补丁必须经过充分测试且明显正确
   • 不能是理论性的修复（如"这可能是个问题..."这类补丁）

2. 规模限制

   • 补丁大小（含上下文）不得超过100行
   • 每个补丁只能修复一个问题（单一职责原则）

3. 问题严重性要求

   • 必须修复实际困扰用户的问题
   • 可接受的修复类型包括：
     • 构建错误（CONFIG_BROKEN除外）
     • 系统崩溃（oops）
     • 系统挂起
     • 数据损坏
     • 真实安全问题
     • 其他严重问题（"这不太好"级别的问题）

4. 特殊情况考虑

   • 发行版内核用户报告的严重性能或交互问题
   • 新设备ID和硬件特性支持
   • 必须附带详细影响说明和Bugzilla链接（如存在）

5. 格式要求

   • 必须遵循内核补丁提交规范
   • 必须已存在于Linus的主线树中

6. 明确排除的类型

   • 理论性竞态条件（除非附带可被利用的详细说明）
   • 琐碎修复（拼写错误、空白清理等）

补丁提交的三种方式

方式一：自动包含（推荐）

在补丁的签核区域添加：

Cc: [e-mail]

补丁合并后会自动进入稳定队列，无需额外操作。

方式二：事后提交

补丁进入主线后，发送邮件至稳定邮件列表，需包含：

• 补丁主题
• 提交ID
• 应用理由
• 目标内核版本

方式三：直接提交

直接发送补丁至稳定邮件列表，必须：

• 验证符合所有规则
• 在变更日志中注明上游提交ID
• 指定目标内核版本

注意：方式三如与原始补丁有差异（如因API变化需要调整），必须在描述中明确说明并合理证明。

特殊标记格式

对于有前置依赖的补丁，可在签核区使用特殊格式：

Cc: <[e-mail]> # 3.3.x: a1f84a3: sched: Check for idle
Cc: <[e-mail]> # 3.3.x: 1b9508f: sched: Rate-limit newidle

这表示需要按顺序cherry-pick指定的提交。

审核流程详解

1. 初步响应

   • 提交者会收到ACK（接受）或NAK（拒绝）
   • 响应时间可能因开发者日程而有所延迟

2. 审核周期

   • 稳定维护者决定开始审核周期
   • 补丁发送给审核委员会和相关子系统维护者
   • 同时抄送linux-kernel邮件列表

3. 决策窗口

   • 审核委员会有48小时做出决定
   • 如有反对意见或新发现问题，补丁将被移除

4. 发布流程

   • 通过审核的补丁加入最新稳定版本
   • 随后发布新的稳定版本

5. 安全补丁特殊流程

   • 安全补丁直接来自内核安全团队
   • 不经过常规审核流程

技术要点解析

1. 版本兼容性：稳定内核补丁需要考虑向后兼容性，特别是当API发生变化时，可能需要调整补丁才能应用于旧版本。

2. 风险控制：严格的准入标准和审核流程确保了稳定分支的质量，防止引入新问题。

3. 自动化支持：通过特定的标记格式（如Cc: [e-mail]），实现了补丁从主线到稳定分支的自动化流转。

4. 责任划分：审核委员会和子系统维护者的双重审核机制，确保了补丁的专业评估。

最佳实践建议

1. 优先使用方式一提交补丁，简化流程
2. 确保补丁描述清晰完整，特别是问题的影响范围和严重性
3. 对于复杂补丁，提供充分的测试证据
4. 关注审核反馈，及时回应问题
5. 了解目标内核版本的特殊性，必要时调整补丁

理解这些规则和流程对于参与Linux内核维护至关重要，特别是对于希望为稳定内核做出贡献的开发者。这些机制共同确保了Linux系统的稳定性和可靠性，为数百万用户提供了坚实的基础。