1. 项目概述一次真实的Linux内核补丁提交之旅如果你和我一样是个常年泡在Linux内核代码里的开发者那么“向社区提交补丁”这件事大概率会出现在你的职业清单上。这不仅仅是为了修复一个bug或添加一个功能更像是一次正式的“技术对话”和“社区融入”的仪式。我最近刚刚完成了一次从问题定位、代码修改、到最终被主线内核mainline接受的完整流程整个过程耗时近两个月踩了不少坑也学到了很多在官方文档里不会明说的“潜规则”。今天我就把这次已验证成功的全步骤拆解开来结合我的实操经验分享给每一位有志于为开源世界添砖加瓦的同道。简单来说这个过程就是把你对内核代码的改进通过一系列标准化的步骤递交给全球的维护者审核并最终合并到官方源码树中。它适合所有层次的开发者无论是刚发现一个拼写错误的新手还是准备实现一个复杂驱动模块的老兵。核心价值在于你能以最规范的方式与世界顶级的开发者协作你的代码将运行在数以亿计的设备上。但别被“高大上”吓到流程本身是清晰、有迹可循的关键在于细节和坚持。2. 内核补丁提交的整体设计与核心思路向Linux内核提交补丁绝非简单的“写代码-发邮件”。它是一套融合了技术、流程和社区文化的系统工程。在动手写第一行代码之前我们必须理解其背后的核心设计逻辑。2.1 为什么流程如此“繁琐”内核是全世界最庞大、最复杂的开源项目之一由数千名开发者共同维护。为了保证代码质量、维持架构一致性和确保历史可追溯性社区演化出了一套极其严谨的协作流程。其核心思路可以概括为“分布式审核邮件驱动”。与使用GitHub/GitLab等平台的Pull Request机制不同Linux内核开发主要依靠邮件列表进行代码评审。每个子系统如网络、内存管理、文件系统都有其专属的维护者和邮件列表。你的补丁需要以邮件的形式发送到正确的列表并抄送给相关的维护者和可能感兴趣的核心开发者。这种设计虽然学习曲线陡峭但优势明显讨论记录公开可查、邮件线程天然形成了评审历史、并且能与许多开发者惯用的命令行工作流无缝集成。2.2 成功提交的三大支柱根据我的经验一次成功的提交依赖于三大支柱缺一不可技术正确性这是根本。你的补丁必须能真正解决问题不能引入回归Regression代码风格必须符合内核规范Linux kernel coding style。流程符合性你必须严格遵循社区定义的提交规范。从如何生成补丁文件到邮件标题的格式、正文的撰写都有明确要求。流程错误会直接导致你的补丁被忽略无论技术多好。沟通有效性内核维护者都是大忙人。你需要用清晰、简洁的语言解释“为什么需要这个改动”并在后续的邮件讨论中积极、礼貌地回应评审意见。这本质上是场技术沟通。我的整体思路是先本地验证再规范提交最后耐心沟通。接下来我们就深入到每个环节的细节中。3. 前期准备环境、工具与心理建设在开始真正的“战斗”前我们需要把“弹药”和“地图”准备好。这个阶段的工作做得越扎实后续的流程就会越顺畅。3.1 开发与通信环境搭建你需要一个用于开发和测试的Linux环境。我强烈建议使用物理机或性能较好的虚拟机因为编译内核是个资源密集型任务。获取内核源码从官方的kernel.org或你感兴趣的子系统仓库克隆代码。通常使用gitgit clone https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git cd linux为了缩小范围你也可以克隆某个稳定分支或子系统的树。配置编译环境安装必要的编译工具链和依赖库。在基于Debian/Ubuntu的系统上可以sudo apt-get install build-essential libncurses-dev bison flex libssl-dev libelf-dev其他发行版请参考对应文档。邮件客户端配置这是最关键也最容易出错的一步。你需要一个能将邮件正确格式化的命令行邮件客户端。社区主流推荐使用git send-email。你需要配置你的SMTP信息。编辑~/.gitconfig文件添加如下配置以Gmail为例请注意使用“应用专用密码”而非普通密码[sendemail] smtpencryption tls smtpserver smtp.gmail.com smtpuser your.emailgmail.com smtpserverport 587 smtppass your-app-specific-password [user] name Your Real Name email your.emailgmail.com注意国内邮箱如QQ、163的SMTP服务可能因网络或安全策略问题导致git send-email发送失败。强烈建议使用国际通用邮箱如Gmail或配置本地邮件服务器如msmtp。这是我踩过的第一个大坑。3.2 内核代码风格与提交信息规范在写代码前请务必阅读Documentation/process/coding-style.rst。内核有自己独特的代码风格如缩进用1个Tab而非8个空格行宽80列等。可以使用scripts/checkpatch.pl脚本来检查你的补丁是否符合规范。更关键的是提交信息Commit Message。这是你与维护者沟通的第一扇窗。一个糟糕的提交信息可能直接导致补丁被拒。标准格式如下子系统: 用一句话简要概括改动不超过50字 空一行 然后详细描述为什么需要这个改动它解决了什么问题以及是如何解决的。 这部分可以分段落写但每行建议不超过72个字符方便在邮件客户端中阅读。 如果修复了一个特定的Bug最好能引用Bug报告或邮件列表讨论的链接。 空一行 最后可以添加诸如“Reported-by:”、“Tested-by:”、“Signed-off-by:”等标签。 其中“Signed-off-by:”是必须的表示你确认贡献者证书DCO。例如net: ethtool: fix potential NULL deref in ethnl_parse_bitset When bit_attr is NULL but mask_attr is not, the current code path could lead to a NULL pointer dereference when trying to access nla_data(bit_attr). This patch adds a check to prevent this. Found by code inspection during a review of related features. Signed-off-by: Zhang San zhangsanexample.com3.3 心理建设与期望管理提交补丁尤其是第一次很可能不会一帆风顺。你可能会收到严厉的代码评审意见或者补丁被搁置数周无人回复。这非常正常。维护者们每天要处理海量邮件他们的批评通常对事不对人目的是保证内核质量。你需要保持耐心和礼貌。就事论事专注于技术讨论。把每一次反馈视为学习机会。 准备好迭代。一个补丁经历5-10轮修改再被接受是家常便饭。4. 核心流程拆解从修改到提交的完整实操假设我们已经发现了一个问题并准备好了修复代码。现在让我们一步步走完整个流程。4.1 第一步在本地创建并验证补丁创建特性分支永远不要在主分支如master或main上直接修改。为你的补丁创建一个独立的分支。git checkout -b fix-null-deref-in-foo进行代码修改使用你熟悉的编辑器进行修改。修改后务必在本地编译测试。至少要用make命令确保能编译通过。如果可能运行相关的内核测试如make modules_install后重启到新内核测试。提交到本地仓库使用git add和git commit。撰写提交信息时务必遵循上一节提到的规范。这是生成补丁的基础。生成补丁文件使用git format-patch命令。如果你想基于某个提交比如HEAD~1生成补丁git format-patch -1 --subject-prefixPATCH HEAD这会生成一个类似0001-subsystem-fix-the-problem.patch的文件。--subject-prefix可以设置为PATCH普通补丁、RFC征求意见稿等。4.2 第二步检查与获取维护者信息在乱发邮件之前必须找到“该发给谁”。运行代码风格检查./scripts/checkpatch.pl 0001-subsystem-fix-the-problem.patch仔细查看所有警告WARNING和错误ERROR并尽可能修复。有些警告可以忽略但你必须清楚为什么可以忽略。获取维护者信息内核源码中的scripts/get_maintainer.pl脚本是你的最佳帮手。它能分析你的补丁修改了哪些文件并给出应该发送给的维护者和邮件列表。./scripts/get_maintainer.pl 0001-subsystem-fix-the-problem.patch输出会是一个列表包含维护者的姓名、邮箱和相关的邮件列表。这个列表就是你待会要发送邮件的收件人。确认邮件列表有时脚本给出的列表可能很庞大。你需要根据补丁的 scope范围进行判断。如果补丁只涉及一个很小的驱动可能只需要发给该驱动的维护者和对应的子系统列表而不是整个内核的通用列表。如果不确定去查阅MAINTAINERS文件。4.3 第三步发送补丁邮件这是最具仪式感也最需要细心的一步。发送测试邮件给自己在正式发送前务必先发给自己进行预览检查格式是否正确。git send-email --toyourselfexample.com --cc-cmd./scripts/get_maintainer.pl --nogit-fallback 0001-*.patch查看收到的邮件确认补丁内容是否以纯文本内联形式正确显示不是附件。邮件标题格式是否正确如[PATCH] subsystem: brief description。邮件正文是否清晰。正式发送确认无误后开始正式发送。使用--to和--cc来指定收件人。通常--to放最主要的维护者或邮件列表--cc放其他相关人员和列表。更简单的方法是让git send-email调用get_maintainer.pl自动添加git send-email --tolinux-kernelvger.kernel.org --cc-cmd./scripts/get_maintainer.pl --nogit-fallback 0001-*.patch这里的--cc-cmd参数会让命令执行后面的脚本并将其输出作为抄送列表。重要提示对于第一个补丁或者你不确定是否找对了人可以先发送一个RFC (Request For Comments)版本。只需在生成补丁时使用--subject-prefixRFC PATCH并在邮件正文开头说明这是一个征求意见稿希望获得初步反馈。这能降低维护者的预期获得更友好的初始指导。4.4 第四步后续迭代与回复邮件发出后就进入了等待和沟通阶段。追踪邮件线程你的补丁邮件会出现在对应的邮件列表归档中如 lore.kernel.org。你需要订阅该列表或定期查看因为所有的讨论都会通过回复你的邮件来进行。处理评审意见维护者或其他开发者可能会回复邮件提出修改意见。你需要认真阅读每一份反馈。在同一个邮件线程内回复。不要另起新邮件。如果同意修改就在本地修改代码然后使用git commit --amend来修改上一次的提交如果只有一次提交或者增加新的提交如果改动较大。然后用git format-patch -v2生成v2版本的补丁。发送v2版本时邮件标题应改为[PATCH v2] ...并在邮件正文最上方清晰地列出相对于v1的变更Changelog例如Changes in v2: - Fixed typo in commit message as suggested by Alex. - Added NULL pointer check before dereferencing ‘ptr‘. - Rebased onto latest linux-next.发送v2补丁时收件人列表应该和v1一致并确保回复到原来的邮件线程。添加 Reviewed-by/Tested-by 标签如果评审者明确表示Reviewed-by: Some One some.oneexample.com或者有测试者反馈测试通过Tested-by: ...你需要将这些标签添加到提交信息中在Signed-off-by:之前。这代表了社区对你代码的认可。这个“修改-发送-等待反馈-再修改”的循环可能会持续多轮直到维护者表示满意并最终将你的补丁应用到他维护的代码树中。5. 高级技巧与深度避坑指南掌握了基本流程后一些高级技巧和“坑点”能极大提升你的成功率和效率。5.1 使用git send-email的进阶配置批量发送多个补丁如果你有一个系列补丁patch seriesgit format-patch可以生成多个文件0001-...,0002-...。使用git send-email 000*.patch可以一次性发送并自动将它们组织成一个有顺序的系列。邮件标题会是[PATCH 0/5] ...,[PATCH 1/5] ...等。覆盖回复地址有时你希望讨论邮件回复到邮件列表而不是你的个人邮箱。可以使用--suppress-cc参数进行精细控制或者配置sendemail.replyto。使用本地邮件代理如果公司网络或邮箱服务商限制SMTP可以配置本地sendmail服务如postfix或msmtp然后让git send-email使用sendmail命令。5.2 如何应对常见的社区反馈“请重基于最新的 linux-next 分支”linux-next是集成了各子系统最新代码的测试树。维护者要求你重基rebase是为了避免你的补丁与即将合并的新代码产生冲突。你需要git remote add next https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git git fetch next git rebase next/master # 解决可能出现的冲突 git push --force-with-lease origin your-branch # 强制更新你的特性分支然后重新生成并发送补丁。“这个改动应该分成三个逻辑独立的补丁”内核社区推崇“一个补丁只做一件事”。如果你的提交混杂了多个不相关的修改会被要求拆分。使用git rebase -i进行交互式变基将一个大提交拆分成多个小提交。长时间无人回复如果补丁发出后一两周都无人问津可以发送一封友好的“ping”邮件。标题可以是[PING][PATCH] ...或[PATCH v1][RESEND] ...正文简单询问是否有人有时间查看。切忌频繁催促。5.3 利用自动化工具提升效率patchwork很多内核子系统使用 Patchwork 系统来跟踪补丁状态。你可以将你的补丁链接到对应的 Patchwork 实例查看其状态New, Under Review, Accepted, Rejected等。b4工具这是一个由内核开发者维护的、专门用于处理内核补丁邮件的强大工具。它可以方便地从邮件列表中拉取补丁系列、应用、打补丁、发送感谢信等。强烈推荐学习和使用。# 使用b4从邮件列表获取一个补丁系列并应用到本地 b4 am -o- https://lore.kernel.org/some-thread | git am6. 实战问题排查与状态追踪实录即使流程完全正确事情也可能不会按计划发展。以下是我在实际操作中遇到的一些典型问题及解决方法。6.1 邮件发送失败或格式错乱这是新手最常遇到的问题。症状git send-email报错提示认证失败、连接超时或邮件发出后内容乱码、补丁变成附件。排查检查SMTP配置确认smtpserver,smtpuser,smtppass正确。特别是密码如果使用Gmail必须使用“应用专用密码”而不是你的谷歌账户密码。检查网络某些网络环境可能屏蔽了SMTP端口。尝试更换网络或使用公司的邮件服务器。检查补丁格式使用git send-email --dry-run先进行干跑它会显示即将发送的邮件内容。检查补丁内容是否在邮件正文中。使用--annotate参数在发送前git send-email会打开编辑器让你最终确认邮件内容。这是一个最后的检查机会。解决如果始终无法解决SMTP问题最后的退路是手动发送。将git format-patch生成的.patch文件内容复制到邮件客户端如Thunderbird的正文中并确保使用纯文本Plain Text模式发送手动填写收件人列表。虽然麻烦但绝对可靠。6.2 补丁被忽略或收到“Not Applicable”回复症状邮件石沉大海或者维护者回复“Not applicable to the current code base”。原因与解决未重基于正确分支你的补丁基于一个太旧的内核版本与维护者当前的代码存在大量冲突。解决方案重新基于维护者正在使用的分支通常是linux-next或该子系统的for-next分支进行变基。补丁描述不清维护者没看懂你的补丁要解决什么问题。解决方案重新撰写提交信息用更清晰的语言描述问题背景、你的解决方案和测试结果。可以参考邮件列表中同类已被接受的补丁是如何描述的。发送给了错误的列表/维护者你的补丁不在该维护者的职责范围内。解决方案再次仔细运行get_maintainer.pl并查阅MAINTAINERS文件确认责任维护者。如果确实找不到可以发送到linux-kernelvger.kernel.org这个通用列表寻求指引。6.3 如何追踪补丁的最终状态你的补丁被维护者回复“Applied”并不代表结束它还需要经过更长的旅程才能进入Linus Torvalds的主线仓库。进入子系统树维护者会将你的补丁应用到他个人的git树中。进入linux-next各子系统的改动会定期被合并到linux-next树中进行集成测试。进入主线mainline在每个合并窗口期Linus会从linux-next和各维护者那里拉取改动合并到他的内核主线中。进入稳定版stable对于重要的bug修复稳定版内核维护者可能会从主线中挑选你的补丁将其向后移植到当前的稳定版内核系列中。你可以通过以下方式追踪Patchwork查看补丁状态是否变为“Accepted”。维护者的git仓库查看你的提交是否出现在其中。https://git.kernel.org/搜索你的提交标题或描述中的关键字。内核发布公告关注最终合并进哪个内核版本如v5.15-rc1。当你最终在https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/中看到自己的提交时那种成就感是无与伦比的。这意味着你的代码成为了全球Linux基础设施的一部分。整个过程虽然充满挑战但每一步的严谨要求都是对一个开源贡献者最好的训练。记住内核社区尊重的是扎实的代码和专业的沟通坚持下去你总能找到自己的位置。
1. 项目概述一次真实的Linux内核补丁提交之旅如果你和我一样是个常年泡在Linux内核代码里的开发者那么“向社区提交补丁”这件事大概率会出现在你的职业清单上。这不仅仅是为了修复一个bug或添加一个功能更像是一次正式的“技术对话”和“社区融入”的仪式。我最近刚刚完成了一次从问题定位、代码修改、到最终被主线内核mainline接受的完整流程整个过程耗时近两个月踩了不少坑也学到了很多在官方文档里不会明说的“潜规则”。今天我就把这次已验证成功的全步骤拆解开来结合我的实操经验分享给每一位有志于为开源世界添砖加瓦的同道。简单来说这个过程就是把你对内核代码的改进通过一系列标准化的步骤递交给全球的维护者审核并最终合并到官方源码树中。它适合所有层次的开发者无论是刚发现一个拼写错误的新手还是准备实现一个复杂驱动模块的老兵。核心价值在于你能以最规范的方式与世界顶级的开发者协作你的代码将运行在数以亿计的设备上。但别被“高大上”吓到流程本身是清晰、有迹可循的关键在于细节和坚持。2. 内核补丁提交的整体设计与核心思路向Linux内核提交补丁绝非简单的“写代码-发邮件”。它是一套融合了技术、流程和社区文化的系统工程。在动手写第一行代码之前我们必须理解其背后的核心设计逻辑。2.1 为什么流程如此“繁琐”内核是全世界最庞大、最复杂的开源项目之一由数千名开发者共同维护。为了保证代码质量、维持架构一致性和确保历史可追溯性社区演化出了一套极其严谨的协作流程。其核心思路可以概括为“分布式审核邮件驱动”。与使用GitHub/GitLab等平台的Pull Request机制不同Linux内核开发主要依靠邮件列表进行代码评审。每个子系统如网络、内存管理、文件系统都有其专属的维护者和邮件列表。你的补丁需要以邮件的形式发送到正确的列表并抄送给相关的维护者和可能感兴趣的核心开发者。这种设计虽然学习曲线陡峭但优势明显讨论记录公开可查、邮件线程天然形成了评审历史、并且能与许多开发者惯用的命令行工作流无缝集成。2.2 成功提交的三大支柱根据我的经验一次成功的提交依赖于三大支柱缺一不可技术正确性这是根本。你的补丁必须能真正解决问题不能引入回归Regression代码风格必须符合内核规范Linux kernel coding style。流程符合性你必须严格遵循社区定义的提交规范。从如何生成补丁文件到邮件标题的格式、正文的撰写都有明确要求。流程错误会直接导致你的补丁被忽略无论技术多好。沟通有效性内核维护者都是大忙人。你需要用清晰、简洁的语言解释“为什么需要这个改动”并在后续的邮件讨论中积极、礼貌地回应评审意见。这本质上是场技术沟通。我的整体思路是先本地验证再规范提交最后耐心沟通。接下来我们就深入到每个环节的细节中。3. 前期准备环境、工具与心理建设在开始真正的“战斗”前我们需要把“弹药”和“地图”准备好。这个阶段的工作做得越扎实后续的流程就会越顺畅。3.1 开发与通信环境搭建你需要一个用于开发和测试的Linux环境。我强烈建议使用物理机或性能较好的虚拟机因为编译内核是个资源密集型任务。获取内核源码从官方的kernel.org或你感兴趣的子系统仓库克隆代码。通常使用gitgit clone https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git cd linux为了缩小范围你也可以克隆某个稳定分支或子系统的树。配置编译环境安装必要的编译工具链和依赖库。在基于Debian/Ubuntu的系统上可以sudo apt-get install build-essential libncurses-dev bison flex libssl-dev libelf-dev其他发行版请参考对应文档。邮件客户端配置这是最关键也最容易出错的一步。你需要一个能将邮件正确格式化的命令行邮件客户端。社区主流推荐使用git send-email。你需要配置你的SMTP信息。编辑~/.gitconfig文件添加如下配置以Gmail为例请注意使用“应用专用密码”而非普通密码[sendemail] smtpencryption tls smtpserver smtp.gmail.com smtpuser your.emailgmail.com smtpserverport 587 smtppass your-app-specific-password [user] name Your Real Name email your.emailgmail.com注意国内邮箱如QQ、163的SMTP服务可能因网络或安全策略问题导致git send-email发送失败。强烈建议使用国际通用邮箱如Gmail或配置本地邮件服务器如msmtp。这是我踩过的第一个大坑。3.2 内核代码风格与提交信息规范在写代码前请务必阅读Documentation/process/coding-style.rst。内核有自己独特的代码风格如缩进用1个Tab而非8个空格行宽80列等。可以使用scripts/checkpatch.pl脚本来检查你的补丁是否符合规范。更关键的是提交信息Commit Message。这是你与维护者沟通的第一扇窗。一个糟糕的提交信息可能直接导致补丁被拒。标准格式如下子系统: 用一句话简要概括改动不超过50字 空一行 然后详细描述为什么需要这个改动它解决了什么问题以及是如何解决的。 这部分可以分段落写但每行建议不超过72个字符方便在邮件客户端中阅读。 如果修复了一个特定的Bug最好能引用Bug报告或邮件列表讨论的链接。 空一行 最后可以添加诸如“Reported-by:”、“Tested-by:”、“Signed-off-by:”等标签。 其中“Signed-off-by:”是必须的表示你确认贡献者证书DCO。例如net: ethtool: fix potential NULL deref in ethnl_parse_bitset When bit_attr is NULL but mask_attr is not, the current code path could lead to a NULL pointer dereference when trying to access nla_data(bit_attr). This patch adds a check to prevent this. Found by code inspection during a review of related features. Signed-off-by: Zhang San zhangsanexample.com3.3 心理建设与期望管理提交补丁尤其是第一次很可能不会一帆风顺。你可能会收到严厉的代码评审意见或者补丁被搁置数周无人回复。这非常正常。维护者们每天要处理海量邮件他们的批评通常对事不对人目的是保证内核质量。你需要保持耐心和礼貌。就事论事专注于技术讨论。把每一次反馈视为学习机会。 准备好迭代。一个补丁经历5-10轮修改再被接受是家常便饭。4. 核心流程拆解从修改到提交的完整实操假设我们已经发现了一个问题并准备好了修复代码。现在让我们一步步走完整个流程。4.1 第一步在本地创建并验证补丁创建特性分支永远不要在主分支如master或main上直接修改。为你的补丁创建一个独立的分支。git checkout -b fix-null-deref-in-foo进行代码修改使用你熟悉的编辑器进行修改。修改后务必在本地编译测试。至少要用make命令确保能编译通过。如果可能运行相关的内核测试如make modules_install后重启到新内核测试。提交到本地仓库使用git add和git commit。撰写提交信息时务必遵循上一节提到的规范。这是生成补丁的基础。生成补丁文件使用git format-patch命令。如果你想基于某个提交比如HEAD~1生成补丁git format-patch -1 --subject-prefixPATCH HEAD这会生成一个类似0001-subsystem-fix-the-problem.patch的文件。--subject-prefix可以设置为PATCH普通补丁、RFC征求意见稿等。4.2 第二步检查与获取维护者信息在乱发邮件之前必须找到“该发给谁”。运行代码风格检查./scripts/checkpatch.pl 0001-subsystem-fix-the-problem.patch仔细查看所有警告WARNING和错误ERROR并尽可能修复。有些警告可以忽略但你必须清楚为什么可以忽略。获取维护者信息内核源码中的scripts/get_maintainer.pl脚本是你的最佳帮手。它能分析你的补丁修改了哪些文件并给出应该发送给的维护者和邮件列表。./scripts/get_maintainer.pl 0001-subsystem-fix-the-problem.patch输出会是一个列表包含维护者的姓名、邮箱和相关的邮件列表。这个列表就是你待会要发送邮件的收件人。确认邮件列表有时脚本给出的列表可能很庞大。你需要根据补丁的 scope范围进行判断。如果补丁只涉及一个很小的驱动可能只需要发给该驱动的维护者和对应的子系统列表而不是整个内核的通用列表。如果不确定去查阅MAINTAINERS文件。4.3 第三步发送补丁邮件这是最具仪式感也最需要细心的一步。发送测试邮件给自己在正式发送前务必先发给自己进行预览检查格式是否正确。git send-email --toyourselfexample.com --cc-cmd./scripts/get_maintainer.pl --nogit-fallback 0001-*.patch查看收到的邮件确认补丁内容是否以纯文本内联形式正确显示不是附件。邮件标题格式是否正确如[PATCH] subsystem: brief description。邮件正文是否清晰。正式发送确认无误后开始正式发送。使用--to和--cc来指定收件人。通常--to放最主要的维护者或邮件列表--cc放其他相关人员和列表。更简单的方法是让git send-email调用get_maintainer.pl自动添加git send-email --tolinux-kernelvger.kernel.org --cc-cmd./scripts/get_maintainer.pl --nogit-fallback 0001-*.patch这里的--cc-cmd参数会让命令执行后面的脚本并将其输出作为抄送列表。重要提示对于第一个补丁或者你不确定是否找对了人可以先发送一个RFC (Request For Comments)版本。只需在生成补丁时使用--subject-prefixRFC PATCH并在邮件正文开头说明这是一个征求意见稿希望获得初步反馈。这能降低维护者的预期获得更友好的初始指导。4.4 第四步后续迭代与回复邮件发出后就进入了等待和沟通阶段。追踪邮件线程你的补丁邮件会出现在对应的邮件列表归档中如 lore.kernel.org。你需要订阅该列表或定期查看因为所有的讨论都会通过回复你的邮件来进行。处理评审意见维护者或其他开发者可能会回复邮件提出修改意见。你需要认真阅读每一份反馈。在同一个邮件线程内回复。不要另起新邮件。如果同意修改就在本地修改代码然后使用git commit --amend来修改上一次的提交如果只有一次提交或者增加新的提交如果改动较大。然后用git format-patch -v2生成v2版本的补丁。发送v2版本时邮件标题应改为[PATCH v2] ...并在邮件正文最上方清晰地列出相对于v1的变更Changelog例如Changes in v2: - Fixed typo in commit message as suggested by Alex. - Added NULL pointer check before dereferencing ‘ptr‘. - Rebased onto latest linux-next.发送v2补丁时收件人列表应该和v1一致并确保回复到原来的邮件线程。添加 Reviewed-by/Tested-by 标签如果评审者明确表示Reviewed-by: Some One some.oneexample.com或者有测试者反馈测试通过Tested-by: ...你需要将这些标签添加到提交信息中在Signed-off-by:之前。这代表了社区对你代码的认可。这个“修改-发送-等待反馈-再修改”的循环可能会持续多轮直到维护者表示满意并最终将你的补丁应用到他维护的代码树中。5. 高级技巧与深度避坑指南掌握了基本流程后一些高级技巧和“坑点”能极大提升你的成功率和效率。5.1 使用git send-email的进阶配置批量发送多个补丁如果你有一个系列补丁patch seriesgit format-patch可以生成多个文件0001-...,0002-...。使用git send-email 000*.patch可以一次性发送并自动将它们组织成一个有顺序的系列。邮件标题会是[PATCH 0/5] ...,[PATCH 1/5] ...等。覆盖回复地址有时你希望讨论邮件回复到邮件列表而不是你的个人邮箱。可以使用--suppress-cc参数进行精细控制或者配置sendemail.replyto。使用本地邮件代理如果公司网络或邮箱服务商限制SMTP可以配置本地sendmail服务如postfix或msmtp然后让git send-email使用sendmail命令。5.2 如何应对常见的社区反馈“请重基于最新的 linux-next 分支”linux-next是集成了各子系统最新代码的测试树。维护者要求你重基rebase是为了避免你的补丁与即将合并的新代码产生冲突。你需要git remote add next https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git git fetch next git rebase next/master # 解决可能出现的冲突 git push --force-with-lease origin your-branch # 强制更新你的特性分支然后重新生成并发送补丁。“这个改动应该分成三个逻辑独立的补丁”内核社区推崇“一个补丁只做一件事”。如果你的提交混杂了多个不相关的修改会被要求拆分。使用git rebase -i进行交互式变基将一个大提交拆分成多个小提交。长时间无人回复如果补丁发出后一两周都无人问津可以发送一封友好的“ping”邮件。标题可以是[PING][PATCH] ...或[PATCH v1][RESEND] ...正文简单询问是否有人有时间查看。切忌频繁催促。5.3 利用自动化工具提升效率patchwork很多内核子系统使用 Patchwork 系统来跟踪补丁状态。你可以将你的补丁链接到对应的 Patchwork 实例查看其状态New, Under Review, Accepted, Rejected等。b4工具这是一个由内核开发者维护的、专门用于处理内核补丁邮件的强大工具。它可以方便地从邮件列表中拉取补丁系列、应用、打补丁、发送感谢信等。强烈推荐学习和使用。# 使用b4从邮件列表获取一个补丁系列并应用到本地 b4 am -o- https://lore.kernel.org/some-thread | git am6. 实战问题排查与状态追踪实录即使流程完全正确事情也可能不会按计划发展。以下是我在实际操作中遇到的一些典型问题及解决方法。6.1 邮件发送失败或格式错乱这是新手最常遇到的问题。症状git send-email报错提示认证失败、连接超时或邮件发出后内容乱码、补丁变成附件。排查检查SMTP配置确认smtpserver,smtpuser,smtppass正确。特别是密码如果使用Gmail必须使用“应用专用密码”而不是你的谷歌账户密码。检查网络某些网络环境可能屏蔽了SMTP端口。尝试更换网络或使用公司的邮件服务器。检查补丁格式使用git send-email --dry-run先进行干跑它会显示即将发送的邮件内容。检查补丁内容是否在邮件正文中。使用--annotate参数在发送前git send-email会打开编辑器让你最终确认邮件内容。这是一个最后的检查机会。解决如果始终无法解决SMTP问题最后的退路是手动发送。将git format-patch生成的.patch文件内容复制到邮件客户端如Thunderbird的正文中并确保使用纯文本Plain Text模式发送手动填写收件人列表。虽然麻烦但绝对可靠。6.2 补丁被忽略或收到“Not Applicable”回复症状邮件石沉大海或者维护者回复“Not applicable to the current code base”。原因与解决未重基于正确分支你的补丁基于一个太旧的内核版本与维护者当前的代码存在大量冲突。解决方案重新基于维护者正在使用的分支通常是linux-next或该子系统的for-next分支进行变基。补丁描述不清维护者没看懂你的补丁要解决什么问题。解决方案重新撰写提交信息用更清晰的语言描述问题背景、你的解决方案和测试结果。可以参考邮件列表中同类已被接受的补丁是如何描述的。发送给了错误的列表/维护者你的补丁不在该维护者的职责范围内。解决方案再次仔细运行get_maintainer.pl并查阅MAINTAINERS文件确认责任维护者。如果确实找不到可以发送到linux-kernelvger.kernel.org这个通用列表寻求指引。6.3 如何追踪补丁的最终状态你的补丁被维护者回复“Applied”并不代表结束它还需要经过更长的旅程才能进入Linus Torvalds的主线仓库。进入子系统树维护者会将你的补丁应用到他个人的git树中。进入linux-next各子系统的改动会定期被合并到linux-next树中进行集成测试。进入主线mainline在每个合并窗口期Linus会从linux-next和各维护者那里拉取改动合并到他的内核主线中。进入稳定版stable对于重要的bug修复稳定版内核维护者可能会从主线中挑选你的补丁将其向后移植到当前的稳定版内核系列中。你可以通过以下方式追踪Patchwork查看补丁状态是否变为“Accepted”。维护者的git仓库查看你的提交是否出现在其中。https://git.kernel.org/搜索你的提交标题或描述中的关键字。内核发布公告关注最终合并进哪个内核版本如v5.15-rc1。当你最终在https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/中看到自己的提交时那种成就感是无与伦比的。这意味着你的代码成为了全球Linux基础设施的一部分。整个过程虽然充满挑战但每一步的严谨要求都是对一个开源贡献者最好的训练。记住内核社区尊重的是扎实的代码和专业的沟通坚持下去你总能找到自己的位置。
