提交Linux内核补丁的方法

目录

1.安装git、git-email软件

2.克隆linux-next分支

kernel.org官方仓库克隆(慢)

清华大学镜像站克隆(快,但是要排队)

克隆中途意外中断的处理方法

3.配置git

填写[sendemail]

填写[user]

4.建立新的开发分支并切换到开发分支

5.修改代码,完成开发和测试工作

6.撰写邮件,提交补丁

撰写邮件

生成补丁

检查补丁

修改补丁

发送补丁

先确认是在窗口期内提交

发送补丁的方法

提交新版本的补丁的注意事项!

4.其它

Linux组织出台AI辅助开发规范

5.新手为Linux内核贡献补丁的方法

1.安装git、git-email软件

sudo apt install git #debian系 sudo yum install git #rehat系 sudo pacman -S git #arch系 sudo dnf install git #fedora系

sudo apt install git-email #debian系 sudo yum install git-email #rehat系 sudo pacman -S git-email #arch系 sudo dnf install git-email #fedora系

2.克隆linux-next分支

根据https://www.kernel.org/doc/man-pages/linux-next.html定义,linux-next分支是为下一个内核合并窗口所准备补丁的汇集区

kernel.org官方仓库克隆(慢)

git clone --depth=1 https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git

*注: 添加--depth=1是浅克隆,只下载最新的一次提交,不拉取任何历史记录,可减小克隆时间

清华大学镜像站克隆(快,但是要排队)

git clone --depth=1 https://mirrors.tuna.tsinghua.edu.cn/git/linux-next.git

克隆中途意外中断的处理方法

删除克隆的目录

rm -rf 克隆的目录

3.配置git

使用vim、nano等编辑器,打开git的配置文件:

nano ~/.gitconfig

注:如果没有.gitconfig,需要先手动创建,[sendemail]下的和[user]下的都要填写

[sendemail] smtpencryption = ssl smtpserver = smtp.yeah.net smtpuser = xxxxxx@yeah.net smtpserverport = 465 smtppass = xxxxxxxx [user] email = xxxxxx@yeah.net name = xxxxxx

填写[sendemail]

这里建议填网易邮箱(@163.com、@126.com或@yeah.net)

这里以@yeah.net为例,

smtpserver=smtp.yeah.net smtpuser=用户完整的邮箱地址 smtppass=网易提供的授权码(保存好,不要外泄!!!!!!),这个不是登录邮箱的密码

获取授权码的方法见网易帮助:https://help.mail.163.com/faqDetail.do?code=d7a5dc8471cd0c0e8b4b8f4f8e49998b374173cfe9171305fa1ce630d7f67ac286624f309a1a7089

注: 网易只会给用户展示一次授权码,用户必须保存好

当然也可以用目录命令填写:

git config --global sendemail.smtpEncryption ssl git config --global sendemail.smtpServer smtp.yeah.net git config --global sendemail.smtpServerPort 25 git config --global sendemail.smtpUser 用户完整的邮箱地址 git config --global sendemail.smtpPass 网易提供的授权码

填写[user]

email: 提交补丁的邮箱地址,用于将提交关联到提交者

name: 提交者的名字(或昵称),用来标记某次提交是谁做的

以一个已经提交的内核邮件为例:

邮件的结尾会有Signed-off-by标签

简而言之,Signed-off-by标签指的是开发者有权提交该补丁(自己创作或基于合规的开源代码修改,同意开发者原创证书(DCO),并愿意对贡献负责,没有这个标签的代码不能被内核或LTSI项目合并

,详细参见https://ltsi.linuxfoundation.org/software/signed-off-process/

4.建立新的开发分支并切换到开发分支

git status git branch develop git checkout develop

5.修改代码,完成开发和测试工作

6.撰写邮件,提交补丁

撰写邮件

git status git add . git commit -s -v

git commit -s -v 中的-s参数指的是自动添加Signed-off-by标签,-v是在提交时，在默认的提交消息编辑器中显示当前提交所引入的详细差异

注: git commit命令会自动打开编辑器,发送者可以撰写邮件,说明为什么要改动,必须言简意赅

撰写邮件的细节参见https://www.bilibili.com/video/BV18rd5YqEVh视频和https://www.bilibili.com/video/BV18j411M77u视频

生成补丁

git format-patch master

检查补丁

生成补丁后,必须使用linux-next自带的脚步检查补丁格式(不是代码逻辑!),必须满足linux社区的要求

./scripts/checkpatch.pl 补丁路径

结果必须0 errors, 0 warnings!!!

修改补丁

如果补丁没有通过checkpatch.pl的检查,可以使用这个通用的命令来执行修改任务:

1.使用文本编辑器(vim、nano、......)修改代码文件

2.

git add 修改的代码文件的路径

3.修改补丁的提交信息

git commit --amend

如果不需要改补丁提交信息,加上--no-edit选项即可

git commit --amend --no-edit

4.重新生成补丁,注意-o后面需要跟的是目录路径,而不是完整的文件路径

git format-patch -1 -o 输出的路径

5.再次检查

./scripts/checkpatch.pl 补丁路径

6.如果补丁是被维护者打回后修改的新版本的补丁,需要在[PATCH]的最后加上v2或v3.......标记,比如:

[PATCH net-next] net: pcs: lynx: add support for 25GBASE-R 如果第一次提交的补丁被维护者打回,要求修改,那么标题写成: [PATCH net-next v2] net: pcs: lynx: add support for 25GBASE-R 如果第二次提交的补丁被维护者打回,要求修改,那么标题写成: [PATCH net-next v3] net: pcs: lynx: add support for 25GBASE-R 以此类推......

发送补丁

先确认是在窗口期内提交

发送补丁前一定要再先确认是在窗口期内提交,比如Networking subsystem (netdev) — The Linux Kernel documentation的Development cycle是这样说的:

Here is a bit of background information on the cadence of Linux development. Each new release starts off witha two week “merge window”where the main maintainers feed their new stuff to Linus for merging into the mainline tree. After the two weeks, the merge window is closed, and it is called/tagged-rc1. No new features get mainlined after this -- only fixes to the rc1 content are expected. After roughly a week of collecting fixes to the rc1 content, rc2 is released. This repeats on a roughly weekly basis until rc7 (typically; sometimes rc6 if things are quiet, or rc8 if things are in a state of churn), and a week after the last vX.Y-rcN was done, the official vX.Y is released.

To find out where we are now in the cycle - load the mainline (Linus) page here:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

and note the top of the “tags” section. If it is rc1, it is early in the dev cycle. If it was tagged rc7 a week ago, then a release is probably imminent. If the most recent tag is a final release tag (without an-rcNsuffix) - we are most likely in a merge window andnet-nextis closed.

简而言之,Linux 内核的开发有固定的周期,每个新版本发布(发布时间见Linus' tree)后,会有两周的“合并窗口”,用于合并新功能,对于带有-next分支的子系统,比如网络子系统,在此期间,net-next分支会关闭,不再接受新特性或非紧急的优化补丁

当然某些子系统的维护者也会主动发邮件告知合并窗口到来,比如[ANN] net-next is OPEN

发送补丁的方法

提交者如果确认当前是在窗口期内,那么可以发送补丁了

建议发送补丁给维护者前,先只发给自己测试一下:

git send-email --to 邮箱地址 补丁路径

确定没问题后,使用脚步查找要发送给的维护者:

./scripts/get_maintainer.pl -f 修改的代码位于的文件路径

可能会输出以下内容:

Andrew Morton <akpm@linux-foundation.org>
linux-mm@kvack.org
linux-kernel@vger.kernel.org

其中Andrew Morton维护者,剩下两个是机器人,发送邮件的时候都要发送(发送给机器人是为了确保能在https://lore.kernel.org/能查到自己的邮件)

--to是主送,填维护者,--cc是抄送,填机器人,当然可以顺带使用--cc填发送者自己的邮箱

git send-email \ --to 维护者1邮箱 \ --to 维护者2邮箱 \ --cc 机器人1邮箱 \ --cc 机器人2邮箱 \ 补丁路径

按照"姓名 <邮箱>"格式来!

比如这样写是正确的:

git send-email \ --to "Andrew Morton <akpm@linux-foundation.org>" \ --cc "linux-mm@kvack.org" \ --cc "linux-kernel@vger.kernel.org" \ 补丁路径

后续就是等待维护者的回复

如果补丁被接受,那么会收到通知邮件

如果补丁被退回,那么提交者根据反馈修改代码,回复维护者发来的邮件,继续参与社区讨论,直至合并

提交新版本的补丁的注意事项!

新版本的补丁必须重新开一个新的邮件线程(即发新邮件),不要直接回复上一个版本的邮件

即当[PATCH] xxx被维护者拒绝时,修改后发送[PATCH v2] yyy这个新的邮件,不能回复[PATCH] xxx的邮件!

比如https://kernelnewbies.org/PatchPhilosophy是这样写的(截取一部分):

Finally, send your new patch or patch seriesas a new threadrather than as a reply to the previous patch or patch series. I.e., a new version of a patch (series) should begin a new thread.

4.其它

Linux组织出台AI辅助开发规范

AI Coding Assistants — The Linux Kernel documentation

中英对照翻译:

Signed-off-by and Developer Certificate of Origin
Signed-off-by 与开发者原创证书

AI agents MUST NOT add Signed-off-by tags. Only humans can legally certify the Developer Certificate of Origin (DCO). The human submitter is responsible for:
AI不得添加Signed-off-by标签。只有人类可以合法地认证开发者原创证书(DCO)。人类提交者负责：

Reviewing all AI-generated code

审查所有AI生成的代码

Ensuring compliance with licensing requirements

确保符合许可要求

Adding their own Signed-off-by tag to certify the DCO

添加自己的 Signed-off-by 标签以认证DCO

Taking full responsibility for the contribution

对贡献承担全部责任

Attribution
归属说明

When AI tools contribute to kernel development, proper attribution helps track the evolving role of AI in the development process. Contributions should include an Assisted-by tag in the following format:
当 AI 工具参与内核开发时,适当的归属有助于追踪 AI 在开发过程中不断演变的作用. 贡献应包含格式如下的Assisted-by标签：

Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2]

Where:
其中：

AGENT_NAME is the name of the AI tool or framework

AGENT_NAME 是AI工具或框架的名称

MODEL_VERSION is the specific model version used

MODEL_VERSION 是所使用的具体模型版本

[TOOL1] [TOOL2] are optional specialized analysis tools used (e.g., coccinelle, sparse, smatch, clang-tidy)

[TOOL1] [TOOL2] 是可选使用的专用分析工具(例如 coccinelle、sparse、smatch、clang-tidy)

Basic development tools (git, gcc, make, editors) should not be listed.
基础开发工具(git、gcc、make、编辑器)不应列出

Example:
示例：

Assisted-by: Claude:claude-3-opus coccinelle sparse

5.新手为Linux内核贡献补丁的方法

Linux内核有大量驱动代码需要清理,包括但不限于单词拼写错误、注释的格式、使用内核文档规定的已经废弃不用的函数(在/Documentation/process/deprecated.rst里面有写)、checkpatch.pl报告的警告和错误、不符合代码规范的(在/Documentation/process/coding-style.rst里面有写),这些清理任务都不需要深入理解驱动的工作原理和细节

可以去阅读https://lore.kernel.org/kernel-janitors/里面的邮件,看看大家是怎么执行清理任务的,也可以看看这个邮件Seeking janitor beginner tasks | Kalyani patra底下的回复