对于许多开发者而言，向 Linux 内核提交第一个补丁是职业生涯中的一个重要里程碑。这个看似简单的目标背后，隐藏着一套与 GitHub 时代完全不同的开发流程、邮件驱动的协作模式，以及需要新手逐一克服的技术门槛。本文将从实战角度出发，梳理首次贡献内核补丁的完整路径，并提供可落地的参数建议与避坑策略。
为什么第一个补丁值得尝试
Linux 内核是全球最庞大的开源协作项目之一，其代码库由数千名来自不同背景的开发者共同维护。对于大多数初次接触内核开发的程序员而言，最大的障碍并非技术能力，而是对陌生工作流程的恐惧。实际上，内核社区对新人相当友好，只要遵循社区约定，即便是一个仅删除两行空格的简单补丁，也能成功进入主线。
首个补丁的价值不仅在于代码本身，更在于它帮助开发者建立对整个内核开发体系的认知。通过亲身体验邮件列表协作、patch 评审流程和版本追踪机制，你将理解开源社区赖以运行的核心机制。这种认知转移到其他大型开源项目时将产生显著的迁移价值。
选择合适的起点：Staging 子系统
对于第一次提交补丁的开发者，强烈建议将目标锁定在内核的 staging 子系统。Staging 是内核代码库中一个特殊的区域，专门用于存放尚处于开发阶段或质量标准未达到主线的驱动程序。这些代码通常由厂商自行开发并贡献，但在编码风格、文档完整性和架构设计上与内核主线存在差距。因此，staging 子系统欢迎并鼓励开发者提交清理性质的补丁，包括代码格式化修正、拼写错误修复、注释完善等改进。
William Durand 分享的经历极具参考价值：他的首个补丁仅删除了drivers/staging/rtl8192e/rtllib_wx.c文件中的两行空行。这个看似微不足道的改动，却完整走完了从本地提交到进入 Linus Torvalds 仓库的全部流程。选择 staging 作为起点的原因很简单：这里的审查门槛相对宽松，维护者对新手更加包容，反馈周期也更短。
环境准备与工具链配置
在动手修改代码之前，你需要配置一套完整的开发环境。首先确保系统已安装 git、gcc 编译器以及内核构建所需的依赖包。以 Ubuntu 为例，运行以下命令安装基础工具：
sudo apt-get install build-essential git libssl-dev libelf-dev
接下来克隆内核仓库。推荐使用 Greg Kroah-Hartman 的 staging 树作为上游，因为大多数 staging 补丁会首先合并到此处：
git clone git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
cd staging
git checkout -b my-first-patch origin/staging
在创建补丁之前，务必通读内核编码风格文档。内核采用与大多数项目不同的代码风格，特别是缩进使用制表符而非空格、花括号 placement 位置等细节。如果使用 vim 编辑器，可以通过配置~/.vimrc添加自动检测内核代码风格：
autocmd FileType C setlocal tabstop=8 shiftwidth=8 noexpandtab
补丁制作的核心要点
内核补丁的制作有严格的格式要求，每一个细节都关系到补丁能否顺利通过自动化检测和人工审查。
提交信息格式
内核采用统一的提交信息格式，通常包含一个标记行和详细描述。标记行的标准格式为[PATCH] 子系统: 简短描述，例如[PATCH] staging: rtl8192e: remove extra blank lines。详细说明部分应解释修改的原因和预期效果，首行与正文之间留有一行空行。
Signed-off-by 行
这是内核开发者身份认证的核心机制。在提交补丁时，必须在提交信息末尾添加Signed-off-by: 你的名字 你的邮箱行。该行表示你确认自己是该代码的原创者，或者有权将其贡献给内核项目，同时接受 Linux 内核开发者证书（DCO）的条款。Git 提供了便捷的方式在提交时自动添加此行：
git commit -s -m "staging: rtl8192e: remove extra blank lines"
其中-s参数自动注入 Signed-off-by 行。
统一 Diff 格式
生成的补丁必须采用统一 diff 格式（unified diff），并包含足够的上下文行数以便审查者理解修改背景：
git format-patch -v1 --subject-prefix="PATCH" -M -n1
生成的.patch文件可直接发送到邮件列表。务必确保补丁能够被git apply正确应用，在提交前执行以下测试：
git apply --check your-patch.patch
邮件列表提交流程
Linux 内核开发完全依赖邮件列表进行代码评审和协作，这与 GitHub 时代的 Pull Request 模式存在本质差异。理解并正确使用邮件工作流是成功提交补丁的关键。
选择正确的邮件列表
每个内核子系统都有对应的邮件列表。对于 staging 相关补丁，应发送到driverdev-devel@linuxdriverproject.org。你可以通过lore.kernel.org搜索历史邮件确认正确的列表地址。发送前务必确认目标列表是否活跃，以及维护者是否接受你正在修改的代码类型。
邮件客户端配置
邮件内容必须为纯文本格式，强烈建议使用终端邮件客户端。内核要求邮件正文在 72 列处自动换行，过长的行会被邮件网关截断导致格式损坏。aerc和mutt都是经过验证的推荐工具。以aerc为例，配置~/.config/aerc/aerc.conf确保启用纯文本模式：
[composer]
format-flowed=true
对于使用 Gmail 的开发者，需要在设置中禁用 RTF 模式并启用 "Plain text only" 选项。无论使用何种客户端，务必在发送前在本地终端预览补丁的实际显示效果。
git send-email 使用
直接使用git send-email是发送补丁的推荐方式，它可以自动处理邮件格式、编码和回复链追踪：
git send-email --to=driverdev-devel@linuxdriverproject.org \
--cc=your-email@example.com \
0001-staging-rtl8192e-remove-extra-blank-lines.patch
首次使用前需要配置 SMTP 服务器。以 Gmail 为例：
git config --global sendemail.smtpserver smtp.gmail.com
git config --global sendemail.smtpserverport 587
git config --global sendemail.smtpencryption tls
git config --global sendemail.smtpuser your-email@gmail.com
审查反馈的应对策略
补丁发出后，耐心等待社区反馈是必经阶段。内核补丁的审查周期从数小时到数周不等，取决于维护者的工作负荷和补丁的复杂度。
常见的初始反馈类型
收到回复时，保持专业和建设性的态度至关重要。常见的反馈包括：编码风格不符、提交信息不够清晰、补丁缺少测试或验证说明、修改范围过于宽泛等。每一条反馈都应认真对待并逐一响应。如果 reviewers 提出了修改建议，重新生成补丁并标记为[PATCH v2]版本发送：
git format-patch -v2 --subject-prefix="PATCH" -M -n1
git send-email --to=driverdev-devel@linuxdriverproject.org \
--in-reply-to=<原始邮件的Message-ID> \
0001-staging-rtl8192e-remove-extra-blank-lines.patch
应对批评的心态建设
内核邮件列表的讨论风格以直接著称，有时措辞可能显得尖锐。然而，这种直接性并非针对个人，而是为了高效推进技术讨论。遇到不理解或不同意的反馈时，礼貌地请求澄清或提供更多背景说明是完全可接受的做法。保持学习心态，将每一次反馈视为加深对内核开发理解的机会。
常见陷阱与规避建议
首次贡献过程中有多个容易踩坑的环节，提前了解可以显著提高成功率。
第一，不要在补丁中混合多个独立的修改。每个补丁应专注于解决一个问题，将格式化修正与功能修改混在一起会导致审查难度倍增且容易被拒绝。
第二，务必在本地完整编译并验证补丁不会引入回归。对于简单的格式化修改，虽然不需要完整的运行时测试，但确保代码能够通过编译检查是基本要求。
第三，遵守邮件礼仪。避免使用 HTML 格式邮件、不要在回复中 top-posting（在引用内容前回复）、始终保留完整的邮件上下文以便追踪讨论线程。
第四，仔细检查补丁的收件人。错误地将补丁发送到不相关的列表会浪费维护者的时间，也可能损害你在社区中的信誉。
首个补丁之后的进阶路径
当第一个补丁成功进入主线后，你可以考虑扩大贡献范围。从 staging 内部的简单清理任务，逐步过渡到其他子系统如文件系统、网络协议栈或内存管理领域。每一个子系统都有其特定的文化和最佳实践，持续学习是长期贡献者的共同特征。
参与代码审查是另一个有价值的进阶方向。通过阅读他人的补丁并提供建设性反馈，你不仅能加深对内核各子系统的理解，还能建立与维护者的协作关系。许多资深内核开发者正是通过持续的社区参与逐步获得信任并承担起维护责任的。
资料来源
本文参考了 William Durand 的首次内核补丁贡献经历（https://williamdurand.fr/2021/02/22/first-patch-in-the-linux-kernel/），以及 Linux 内核官方补丁提交指南（https://www.kernel.org/doc/html/v6.5/process/submitting-patches.html）。