linux内核补丁教程，提交内核补丁到Linux社区的步骤简介
向Linux社区提交补丁并不频繁，某⼀次提交后可能了然于胸，过段时间总会忘记，于是就有了这篇⽂章
这篇⽂章是我真实提交的步骤，没有严格按官⽅的要求和建议来，但能覆盖⼤多数问题
如果希望详细学习如何提交，参考《如何让你的改动进⼊内核》
下载代码
在官⽹下载最新代码，或者通过MAINTAINERS寻找对应⼦系统的仓库代码。
以我要提交pstore的⼦系统为例，在MAINTAINERS中找到以下信息：
PSTORE FILESYSTEM
M: Kees Cook
M: Anton Vorontsov
M: Colin Cross
M: Tony Luck
S: Maintained
T: git git:///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/
K: \b(pstore|ramoops|blkoops)
既然⼦系统有独⽴仓库分⽀，那就下载这个分⽀的代码，并切换到对应分⽀
git clone git:///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
<
<
在封⾯补丁⾥，就会列出了系列补丁包含哪些补丁？改了啥⽂件？如下：
[...]
Subject: [PATCH v5] *** SUBJECT HERE ***
*** BLURB HERE ***
WeiXiong Liao (1):
mtd: ...
drivers/mtd/Kconfig | 8 +
drivers/mtd/Makefile | 1 +
[...]
3 files changed, 540 inrtions(+)
其中，封⾯补丁⾥⾯邮件头和正⽂需要⾃⼰写，可别冒失就这么发出去了
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 (maintainer:PSTORE FILESYSTEM)
Anton Vorontsov (maintainer:PSTORE FILESYSTEM)
Colin Cross (maintainer:PSTORE FILESYSTEM)
[...]
linux-doc@ (open list:DOCUMENTATION)
linux-kernel@ (open list)
linux-mtd@ (open list:MEMORY TECHNOLOGY DEVICES (MTD))
因为我的是系列补丁，涉及多个⼦系统，所以获取到的邮件地址很多。
上⾯显⽰的地址中，很明显最后linux-开头的三⾏不是代码reviewer，类似于订阅转发地址的存在。把邮件发给这⼏个地址，就会转发给所有订阅了⼦系统的⼈。
发送邮件
我们⽤ git nd-mail 发送邮件，简单，舒⼼
git nd-mail --to --to .... --cc linux-XXXX@xxxx --cc ... 00*.patch
把上⾯获取的maintainer地址，⽤ --to 指定，订阅地址改⽤抄送 --cc
当然，在这之前，需要在git中配置你的ndmail信息
$ cat ~/.gitconfig
[...]
[ndemail]
smtprver = ...
smtprverport = 465
smtpencryption = ssl
smtpur = ...
响应质疑与等待合并
如果有maintainer对你的补丁有疑惑，别担⼼，他们邮件提问，我们邮件回复。邮件回复的细节不累述了。
