900字范文 > 向 Linux kernel 社区提交patch补丁步骤总结（已验证成功）

向 Linux kernel 社区提交patch补丁步骤总结（已验证成功）

时间：2022-09-14 06:30:36

一、详细步骤

本次使用CentOS Linux8系统虚机，git下载修改源码提取patch并邮件给maintainer。

1.安装git和git send-email

yum install gityum install git-email

2.配置git和smtp

git config --global user.name "xxx"git config --global user.email "xxx@"

配置smtp

vi ~/.gitconfig //在文件末尾添加[sendemail][user]name = xxxemail = xxx@[core]editor = vim[gitreview]username = xxx[commit]template = /root/.gitcommit[sendemail]smtpencryption = sslsmtpserver = smtpuser = xxx@smtpserverport = 465

3.通过git clone下载或直接下载压缩包后解压。

（以下方式选择其一即可：

进入/torvalds/linux下载最新版本。

进入/pub/scm/linux/kernel/git/next/linux-next.git查看最新版

有些模块的Maintainer还会维护自己的代码分支，详细信息可以linux内核源码的MAINTAINERS文件中找到，以driver-core模块为例：

/* MAINTAINERS */
DRIVER CORE, KOBJECTS, DEBUGFS AND SYSFS
M: Greg Kroah-Hartman <gregkh@>
R: "Rafael J. Wysocki" <rafael@>
S: Supported
T: gitgit:///pub/scm/linux/kernel/git/gregkh/driver-core.git
F: Documentation/core-api/kobject.rst
F: drivers/base/
F: fs/debugfs/
F: fs/sysfs/
F: include/linux/debugfs.h
F: include/linux/kobj*
F: lib/kobj*

）

进入/官网-->[browse]-->commit 下载gz压缩包（本次使用，.2.22）

tar -zxf linux-5.17-rc7.gz

进入linux-5.17-rc7，执行

git init // commit后才能创建新分支git statusgit add .git commit -m "linux-5.17-rc7"

4.提前配置~/.gitcommit文件

新建一个模板，按如下格式（提交时必须修改一下，不然认为空操作拒绝commit；每行不要超过75个字符）：

drivers: fix some errorWhy I do these changes and how I do it.# Signed-off-by: My Name <my_email@> (gitcommit -s自动添加，so不需要)

第一部分是 short description，以子系统名打头，比如 mm，注意冒号后面加个空格，不知道子系统名的可以看看你修改的这个文件的修改历史，看看之前的开发者是怎么写的。这一部分需要使用一句简短的话描述你所做的修改，要让维护者一眼就看出这个 Patch 大概干了什么事。第二部分是 the body of your patch，这一部分要详细的解释你为何要做这个修改，以及怎么做的，注意时态用现在时，语态用主动形式。第三部分是之前的 -s 参数自动加上的，不用管。必须要注意的是，这三部分之间都要有一个空行隔开。

5.修改Linux kernel源码并提交

加入自己本次要提交的patch，修改代码后，执行下面的命令

git statusgit add .git commit -s /* -s：自动在commit中添加Signed-off-by行 */

注意 git commit 命令会自动打开编辑器让你编辑 Commit 信息，

-s 参数可以自动在你的 commit 信息下加上一行Signed-off-by: My Name <my_email@>

-v 参数会在你的 Commit 信息下方显示出你做的修改，确保你能再三检查自己的改动，这一个参数不是必须的。

注意，linux社区对commit信息的格式有严格要求，具体参考Documentation/process/submitting-patches.rst文档，大致如下（同前所述）：

module name: fix some bugs
why and how
Signed-off-by: Name <xxx@>

补丁的第一行是标题，首先是模块名称，可使用git log查看所修改文件以前的提交记录（前提是git了网站上的工程才会有相应log记录，tar解压的没有），举例如下：

git log drivers/base/bus.c
输出：
commit a4723041857eaa35f189d237da769c4c63235544
Author: Greg Kroah-Hartman <gregkh@>
Date: Mon Oct 29 16:31:26 +0100
driver core: drop use of BUS_ATTR()
We are trying to get rid of BUS_ATTR() so drop the last user of it from
the tree. We had to "open code" it in order to prevent a function name
conflict due to the use of DEVICE_ATTR_WO() earlier in the file :(
Cc: "Rafael J. Wysocki" <rafael.j.wysocki@>
Signed-off-by: Greg Kroah-Hartman <gregkh@>

可见模块名称为driver core。

commit信息添加完成后保存退出，此时执行git log即可看到刚刚的提交详情。

[root@localhost linux-5.17-rc7]# git logcommit 2486b0f3cb0ec7a17864d70a41739b182bf375dd (HEAD -> master)Author: xxx<xxx@>Date: Thu Mar 24 17:50:28 +0800tools:iio: Fix the potential stack overflow riskAdd judgment to fix the potential stack overflow risk.Signed-off-by: xxx<xxx@>commit b4100028603a11f14602add0bd54fe35c66a5017Author: xxx<xxx@>Date: Tue Mar 8 11:19:39 +0800kernel-5.17-rc7

如果 commit 之后还想修改 Commit 信息的话需要使用命令 git commit --amend -v。

6.生成patch

使用下面的命令生成patch，命令完成后，当前目录就可以看到 Patch 文件了。

git format-patch --subject-prefix='PATCH' -1

其中--subject-prefix 是为邮件标题添加个前缀

由于到linus和linux内核的电子邮件流量很高，通常会在主题行前面加上[PATCH] 前缀. 这使Linus和其他内核开发人员更容易将补丁与其他电子邮件讨论区分开。

7.patch格式检查

运行以下命令检查你的 Patch 格式有没有问题，要做到 0 errors, 0 warnings。

./scripts/checkpatch.pl 0001-drivers-format-the-code.patch

8.测试发送

在正式发送之前，先发给自己测试一下：

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

一切正常的话，就可以收到邮件了，检查下格式什么的是否和预想的一样。

9.内核编译检查

进入linux-5.17-rc7目录下（Makefile文件所在目录）运行

make menuconfig

在图示界面中确认本次修改的部分（本次为driver/vfio部分）均已被设置为编译y或[*]或[m]

make bzImage //编译内核

等待编译……

解决可能出现的错误……

编译成功。

对于改动的部分是内核代码，一定要确认make menuconfig里选中了自己改动的模块，不然不会编译。这个一般可以从编译记录中查找是否有 CC …… xxx.o 来确认改动的xxx部分已被编译。第一次编译内核需要约2h，以后再编只会编译所更改的模块所以会很快，当然也可以选择只编译内核的某个模块。

对于改动的部分是非内核代码（如某些tools工具其实只是一些检查或生成工具），该部分不会被编入内核中，可以通过进入到该目录下直接执行 make 编译来检查更改后的代码有无bug，只要在该目录下生成xxx.o即可证明改动后的代码没有问题。

10.查找邮件maintainer

既然 Patch 已经测试完毕，那么是时候发送给上游维护者了。运行以下命令（二选一均可）找出你应该把 Patch 发给谁。

./scripts/get_maintainer.pl -f drivers/vfio/vfio_iommu_type1.c./scripts/get_maintainer.pl 0001-xxxx.patch

该命令输出如下

Alex Williamson <alex.williamson@> (maintainer:VFIO DRIVER)
Cornelia Huck <cohuck@> (reviewer:VFIO DRIVER)
kvm@ (open list:VFIO DRIVER)
linux-kernel@ (open list)

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

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

11.发送patch

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

-cc cohuck@ \

-cc kvm@ \

-cc linux-kernel@

之后你的 Patch 就发送给上游维护者并抄送到对应的邮件列表了。

12.后续（等待合入或邮件回复）

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

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

<commit message>...Signed-off-by: Author <author@mail>---V2 -> V3: Removed redundant helper functionV1 -> V2: Cleaned up coding style and addressed review commentspath/to/file | 5+++--...

如果是回复补丁的话，可以按照如下格式发送新版patch或说明txt

git send-email \

--in-reply-to=0615073348.6891-1-xxx@ \~~(Message-ID)~~

--to=xxx@ \

--cc=xxx@ \

/path/to/YOUR_REPLY

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