gfreewind/kernel_comment项目：Linux内核补丁提交指南详解

前言

在Linux内核开发过程中，正确提交补丁是开发者必须掌握的核心技能。本文将深入解析Linux内核补丁提交的完整流程和最佳实践，帮助开发者提高补丁被接受的概率。

获取内核源代码

在开始修改前，必须获取最新的内核源代码树。推荐使用Git工具克隆主线仓库：

git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

但要注意，大多数子系统维护者都有自己的开发树，补丁应该基于这些子树而非主线树。可以通过MAINTAINERS文件中的"T:"条目查找相应子树。

补丁生成规范

手动生成补丁

如果必须手动生成补丁，应使用diff -up或diff -uprN命令：

# 单文件补丁示例
SRCTREE=linux
MYFILE=drivers/net/mydriver.c

cd $SRCTREE
cp $MYFILE $MYFILE.orig
vi $MYFILE  # 进行修改
cd ..
diff -up $SRCTREE/$MYFILE{.orig,} > /tmp/patch

多文件补丁生成

对于涉及多个文件的修改：

MYSRC=/devel/linux

tar xvfz linux-3.19.tar.gz
mv linux-3.19 linux-3.19-vanilla
diff -uprN -X linux-3.19-vanilla/Documentation/dontdiff \
    linux-3.19-vanilla $MYSRC > /tmp/patch

注意使用dontdiff文件排除构建过程中生成的临时文件。

补丁描述规范

优秀的补丁描述应包含以下要素：

1. 问题描述：清晰说明要解决的问题及其重要性
2. 影响范围：详细描述对最终用户的影响
3. 量化指标：性能优化等改进需提供具体数据支持
4. 技术细节：用通俗语言解释代码变更的技术原理

描述应使用命令式语气，例如"使xyzzy执行frotz"而非"本补丁使xyzzy执行frotz"。

引用规范

• 引用Bug时需包含Bug编号和URL
• 引用邮件列表讨论需提供归档URL
• 引用特定提交需包含SHA-1 ID前12位和提交摘要

示例：

Commit e21d2170f36602ae2708 ("video: remove unnecessary platform_set_drvdata()")...

修复特定提交引入的问题时使用Fixes标签：

Fixes: e21d2170f366 ("video: remove unnecessary platform_set_drvdata()")

补丁拆分原则

应将每个逻辑变更拆分为独立补丁：

1. 错误修复和新功能增强应分开
2. API更新和使用新API的驱动应分开
3. 但单个变更涉及多个文件时应保持在一个补丁中

确保内核在应用每个补丁后都能正常构建和运行，这对使用git bisect的开发者很重要。

代码风格检查

提交前必须使用scripts/checkpatch.pl检查代码风格问题。检查结果分为三个级别：

1. ERROR：极可能错误
2. WARNING：需要仔细审查
3. CHECK：需要思考

特别注意：移动代码时不应对其进行修改，移动和修改应分属不同补丁。

收件人选择策略

1. 必须抄送相关子系统的维护者（通过MAINTAINERS文件查找）
2. 选择合适的邮件列表（避免直接发送到[e-mail]）
3. 安全补丁发送至[e-mail]
4. 稳定版补丁添加Cc: [e-mail]
5. 用户空间接口变更需通知man-pages维护者和[e-mail]

邮件格式要求

1. 必须以内联纯文本形式发送补丁
2. 禁止使用MIME附件、压缩包或超链接
3. 超过300KB的补丁应先上传到服务器，邮件中只包含URL
4. 主题行必须包含[PATCH]前缀

评审响应指南

1. 必须回应所有评审意见
2. 对未导致代码变更的评审意见也应回复或更新变更日志
3. 礼貌感谢评审者的时间投入
4. 保持耐心，通常一周内会收到回复
5. 至少等待一周后再跟进或重新提交

结语

掌握这些补丁提交规范将显著提高你的内核贡献被接受的概率。记住，内核开发是协作过程，清晰的沟通和规范的流程与代码质量同等重要。