提交内核补丁到Linux社区的步骤

简介

向Linux社区提交补丁并不频繁,某一次提交后可能了然于胸,过段时间总会忘记,于是就有了这篇文章

这篇文章是我真实提交的步骤,没有严格按官方的要求和建议来,但能覆盖大多数问题

如果希望详细学习如何提交,参考《如何让你的改动进入内核》

下载代码

在官网下载最新代码,或者通过MAINTAINERS寻找对应子系统的仓库代码。

以我要提交pstore的子系统为例,在MAINTAINERS中找到以下信息:

PSTORE FILESYSTEM
M:  Kees Cook <keescook@chromium.org>
M:  Anton Vorontsov <anton@enomsg.org>
M:  Colin Cross <ccross@android.com>
M:  Tony Luck <tony.luck@intel.com>
S:  Maintained
T:  git git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git for-next/pstore
F:  fs/pstore/
F:  include/linux/pstore*
F:  drivers/firmware/efi/efi-pstore.c
F:  drivers/acpi/apei/erst.c
F:  Documentation/admin-guide/ramoops.rst
F:  Documentation/admin-guide/pstore-block.rst
F:  Documentation/devicetree/bindings/reserved-memory/ramoops.txt
K:  \b(pstore|ramoops|blkoops)

既然子系统有独立仓库分支,那就下载这个分支的代码,并切换到对应分支

git clone git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git pstore-tree
git checkout for-next/pstore

创建补丁

在下载的最新代码仓库中,本地提交自己的补丁后,就可以把补丁提取出文件来。

如果是单个补丁,用下面的命令:

git format-patch --subject-prefix='PATCH' -i HEAD~

如果是系列补丁,用下面的命令:

git format-patch --cover-letter --subject-prefix='PATCH' -N #这里的N是你要提取的补丁个数

上面两个命令比较通用了,其中

subject-prefix 是为邮件标题添加个前缀
cover-letter 是为系列邮件创建封面邮件

邮件前缀

一个邮件可有多个邮件前缀。有以下常见的邮件前缀,我的理解不确定是否准确,仅供参考

前缀 含义
PATCH 常规的且正式的补丁
RFC 不是要正式提上去的,希望一起讨论这个补丁,用来说明方向,看看意见
RESEND 邮件发过了但好几周都没人鸟,可能被遗忘了,重新发

如果根据maintainer的意见,修改后重新提交,则需要在前缀后面加上版本。

例如第5个版本:

git format-patch --subject-prefix='PATCH v5' -i HEAD~

提取出来的补丁,效果大概是这样:

[...]
Subject: [PATCH v5] ....
[...]

邮件封面

当有多个补丁来做某一件事情,我们需要提交系列补丁,那么最好有个邮件封面,介绍这系列补丁

那么,就会多出个0000编号的补丁:

0000-cover-letter.patch
0001-...
0002-...

在封面补丁里,就会列出了系列补丁包含哪些补丁?改了啥文件?如下:

[...]
Subject: [PATCH v5] *** SUBJECT HERE *** 

*** BLURB HERE ***

WeiXiong Liao (1):
  mtd: ...

 drivers/mtd/Kconfig     |   8 + 
 drivers/mtd/Makefile    |   1 + 
[...]
 3 files changed, 540 insertions(+)

其中,封面补丁里面邮件头和正文需要自己写,可别冒失就这么发出去了

SUBJECT HERE : 封面邮件头,一句话总结系列邮件
BLURB HERE : 封面邮件正文,讲讲系列邮件是为了做什么

编译检查

编译进内核和编译成模块,都要试试,确保都能编译过

风格检查

Linux内核有提供脚本进行补丁的风格检查,执行下面命令:

$ ./scripts/checkpatch.pl 00*.patch

脚本爆出错误啦,改!在本地仓库改,然后提交到本地仓库,重新提出补丁,再次检查。只至没有报错为止。

错误都改!如果是警告,建议改,除非你觉得修改是合理的,可以忽略

还有一些是误报/建议,自己酌情看看是否要修,例如:

WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#71: 
new file mode 100644

上面警告信息显示添加了新文件,需要我们确认新文件是否有在MAINTAINERS的记录中。实际上是有的,因为MAINTAINERS中文件是模糊匹配的,刚好囊括了我新添加的文件,因此可以忽略这警告。

确定邮件接受人

不知道把邮件发给谁?别怕,Linux内核牛叉到有提供脚本获取邮件接收人地址:

$ ./scripts/get_maintainer.pl 00*.patch

会比较慢,慢慢等,输出结果参考如下:

Kees Cook <keescook@chromium.org> (maintainer:PSTORE FILESYSTEM)
Anton Vorontsov <anton@enomsg.org> (maintainer:PSTORE FILESYSTEM)
Colin Cross <ccross@android.com> (maintainer:PSTORE FILESYSTEM)
[...]
linux-doc@vger.kernel.org (open list:DOCUMENTATION)
linux-kernel@vger.kernel.org (open list)
linux-mtd@lists.infradead.org (open list:MEMORY TECHNOLOGY DEVICES (MTD))

因为我的是系列补丁,涉及多个子系统,所以获取到的邮件地址很多。

上面显示的地址中,很明显最后linux-开头的三行不是代码reviewer,类似于订阅转发地址的存在。把邮件发给这几个地址,就会转发给所有订阅了子系统的人。

发送邮件

我们用 git send-mail 发送邮件,简单,舒心

git send-mail --to <maintainerA> --to <maintainerB> .... --cc linux-XXXX@xxxx --cc ... 00*.patch

把上面获取的maintainer地址,用 --to 指定,订阅地址改用抄送 --cc

当然,在这之前,需要在git中配置你的sendmail信息

$ cat ~/.gitconfig
[...]
[sendemail]
    smtpserver = ...
    smtpserverport = 465 
    smtpencryption = ssl 
    smtpuser = ...

响应质疑与等待合并

如果有maintainer对你的补丁有疑惑,别担心,他们邮件提问,我们邮件回复。

邮件回复的细节不累述了。

声明:该文章系转载,转载该文章的目的在于更广泛的传递信息,并不代表本网站赞同其观点,文章内容仅供参考。

本站是一个个人学习和交流平台,网站上部分文章为网站管理员和网友从相关媒体转载而来,并不用于任何商业目的,内容为作者个人观点, 并不代表本网站赞同其观点和对其真实性负责。

我们已经尽可能的对作者和来源进行了通告,但是可能由于能力有限或疏忽,导致作者和来源有误,亦可能您并不期望您的作品在我们的网站上发布。我们为这些问题向您致歉,如果您在我站上发现此类问题,请及时联系我们,我们将根据您的要求,立即更正或者删除有关内容。本站拥有对此声明的最终解释权。