向kernel.org提交patch流程

一 配置git和smtp

git

git config --global user.name “xxx”
git config --global user.email “xxx@xxx.com”
需要下载email相关的包 - libmailtools-perl 等

smtp

vi ~/.gitconfig //在文件末尾添加[sendemail]

[user]

    name = xxx
 
    email = xxx@xxx.com

[core]

    editor = vim

[gitreview]

    username = xxx

[commit]

    template = /root/.gitcommit

[sendemail]

    smtpencryption = ssl
 
    smtpserver = smtp.exmail.qq.com   //根据个人邮箱进行修改
 
    smtpuser = xxx@xxx.com   //根据个人邮箱进行修改
 
    smtpserverport = 465

上述修改完成后要记得保留客户端授权密码，一般是会点击开启 POP/SMTP时生成

二 根据修改内容编写commit信息

查询修改补丁需要发送给maintainer、commiter的相关人员是谁：

1、可以查看修改相同文件之前提交信息，eg：
git log -p drivers/spi/spi-cadence-quadspi.c

2、固定格式：

spi: cadence-quadspi: setup ADDR Bits in cmd reads

xxx

Signed-off-by: Dhruva Gole <d-gole@ti.com>
Link: https://lore.kernel.org/r/20230125081023.1573712-4-d-gole@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>

应该是固定格式，表示我们要修改的源文件， 后面紧接着是一条概括性的语句，概况本次提交的主要内容
接着下面用一个段落来详细描述本次提交的内容，可以介绍一下修改的内容，修改的原因等等
第三段是签名的内容，签名主要是为提交者署名，正常提交时，我们在 commit 时加入 -v 参数后会自动在commit message后面添加上自己的签名

第一条内容就是提交者的签名

第二条内容是这条提交的邮件讨论链接，记录了从代码提交到交流到最终合并的过程

第三条内容是合并你的代码的人员的签名。

其中第一条是自己添加，第二条和第三条是在合并代码时自动添加的。

三 根据修改内容生成patch

git format-patch --subject-prefix=‘PATCH’ -1

–subject-prefix 是为邮件标题添加个前缀，

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

patch检查：
./scripts/checkpatch.pl 0001-drivers-format-the-code.patch
需要做到0 errors和0warnings
内核代码编译，只编译有所更改的模块：

四 邮件发送patch

通过邮件方式发送patch

1）做测试，发给自己

git send-email --to xxx@xxx.com --cc xxx@xxx.com 0001-xxxx-.patch

2）测试没问题后，查找maintainer的邮件，下面两种方式都可：

./scripts/get_maintainer.pl -f drivers/vfio/vfio_iommu_type1.c

./scripts/get_maintainer.pl 0001-xxxx.patch

对于小的补丁，你也许会CC到搜集琐碎补丁的邮件列表(Trivial Patch Monkey) trivial@kernel.org，那里专门收集琐碎的补丁。下面这样的补丁会被看作“琐碎的” 补丁

文档的拼写修正。
修正会影响到 grep(1) 的拼写。
警告信息修正(频繁的打印无用的警告是不好的。)
编译错误修正（代码逻辑的确是对的，只是编译有问题。）
运行时修正（只要真的修正了错误。）
移除使用了被废弃的函数/宏的代码(例如 check_region。)
联系方式和文档修正。
用可移植的代码替换不可移植的代码（即使在体系结构相关的代码中，既然有人拷贝，只要它是琐碎的）
任何文件的作者/维护者对该文件的改动（例如 patch monkey 在重传模式下）
3）发送patch

git send-email --to alex.williamson@redhat.com \

-cc cohuck@redhat.com \

-cc kvm@vger.kernel.org \

-cc linux-kernel@vger.kernel.org

/path/to/YOURPATCH

4）后续

静静的等待维护者的邮件通知吧，一般几天之内就会回复邮件然后表示Apllied，Thanks或告知预计要合入到下一版本的如linux-5.18，有时第二天就回复一般是patch有问题。

如果patch有问题，需要回复邮件说明疑问，或直接按maintainer的要求修改补丁变成V2版本再次提交。再次提交V2版本需要注意在补丁说明中添加v1->v2的变化（patch中—分隔符之后）：

...

Signed-off-by: Author author@mail

V2 -> V3: Removed redundant helper function
V1 -> V2: Cleaned up coding style and addressed review comments

path/to/file | 5++±-
…
如果是回复补丁的话，可以按照如下格式发送新版patch或说明txt

git send-email \

--in-reply-to=20220615073348.6891-1-xxx@xxx.com \                  (Message-ID)

--to=xxx@xxx.com \

--cc=xxx@xxx.org \

/path/to/YOUR_REPLY

其中，Message-ID可以在任一带有官方性质的邮件记录网址如（Project List - Patchwork，All of lore.kernel.org，Projects | Patchew 等等）查看，一般是“时间戳+邮件地址”的形式，最后是你的补丁或文本注释。