[系统运维]Linux 之十五 Kernel 仓库、Kernel 协作方式、订阅邮件列表、提交 PATCH

kernel.org

??kernel.org 是 Linux 内核源代码的最主要分发站点，主要包括 kernel.org 网站及 Git 存储库等基础设施。其主要作用是托管 Linux 内核开发人员和各种 Linux 内核发行版的维护者使用的源代码存储库。此外，它也是 Linux Kernel 协作开发的控制中心。

??Linux Kernel 的源代码托管运作方式不同于那些使用 GitHub、GitLab 等公共在线代码托管平台的开源软件（占大多数，例如 nodejs、Python），也不同于那些使用自己用 GitLab、Gitea 搭建的专用托管平台的开源软件（少数，例如 U-Boot），更不同于那些仅以 tar 包方式提供源代码的开源软件（极少，例如 ARM GNU Toolchain）。其中一个重要原因就是这些在线平台很难支持 Linux Kernel 这样大型的项目。

??目前，Linux Kernel 采用自己搭建的 Git 代码托管平台来管理 Linux Kernel 源代码，每一个部分都有自己独立的源代码仓库，并独立维护，然后再由专人再进行合并为一个整体，并且 Linux Kernel 至今还在使用邮件列表和补丁提交的开源协作方式。早期的一些开源项目都是使用邮件列表及 IRC 这两种方式进行协作开发：

• 邮件列表（Mailing List） 的起源能够追溯到 1975 年，是互联网上最早的社区形式之一，也是互联网上的一种重要工具，用于各种群体之间的信息交流和信息公布。
  
• IRC（Internet Relay Chat） 的中文一般称为互联网中继聊天。它是由芬兰人 Jarkko Oikarinen 于 1988 年首创的一种网络聊天协议。IRC 的工作原理非常简单：A 与 B 聊天，流程是 A ? C ? B，其中，C 就是 Relay，一般就是服务器。
  

??多数使用自建 Git 托管平台的开源软件同时也会在 GitHub 等公共在线托管平台上建立镜像仓库。例如 Yocto Project 相关代码仓库，Linux Kernel 的几个主要仓库等等。注意，镜像仓库往往都是为了查看源码的方便，一般官方都不推荐在镜像仓库中反馈问题等协作。

The Linux Kernel Organization

??Linux Kernel Organization 是一家向公众分发 Linux Kernel 和其他开源软件的公益公司。成立于 2002 年，总部位于位于加利福尼亚州洛杉矶市，被美国国税局认定为 501?3 私人运营基金会。

??Linux Kernel Organization 负责运营 kernel.org 网站及相关基础设施。但是，Linux Kernel Organization 貌似没啥人，它由 The Linux Foundation 管理，资金、技术支持、人力支持等也都是由 The Linux Foundation 提供。

The Linux Foundation

??Linux 基金会（The Linux Foundation）是 2000 年由开源码发展实验室（Open Source Development Labs，OSDL）与自由标准组织（Free Standards Group，FSG）联合起来成立的。致力于促进，保护和推进 Linux 内核协同开发，并支持“历史上最大的共享技术资源”。

??Linux 基金会赞助 Linux 创建者 Linus Torvalds 和首席维护者 Greg Kroah-Hartman 的工作，也通过活动、培训和认证以及开源项目扩展了其支持计划。此外，Linux 基金会下还有许多独立的项目（例如 Xen Project、Yocto Project）。

Kernel 源码仓库

??根据不同的开发情况，Kernel 将源代码分为了一个主线仓库（Mainline）、一个稳定版仓库（Stable）、一个集成测试仓库（Linux-next）和众多的子系统仓库（Subsystem）等一系列独立的仓库。每个仓库都有专人进行维护，独立开发，互相不影响！

??如果在国内直接访问 Kernel 的原始代码仓库（貌似是位于荷兰），速度是非常慢的。不过好消息是，Code Aurora Forum 在北京提供了一个 Linux Kernel 的镜像仓库：https://kernel.source.codeaurora.cn/。这个镜像仓库与 git.kernel.org 是一模一样的，并且都是由同一个团队在管理，因此其更新速度与 git.kernel.org 基本也是同步的。

1. 国内还有一些第三方的 Linux Kernel 的镜像仓库，例如 清华大学开源软件镜像站。这些第三方镜像仓库的更新速度往往不是很即使，并内容也不够全面
2. 如果直接在 Windows 下 clone Linux Kernel 源代码（其中有很多符号连接，Windows 不支持），在 clone 的最后会报错，但是不影响代码阅读。
3. 不要视图直接往 https://git.kernel.org 仓库推送代码，只有对应仓库的维护人员才有权限

??所有的 Kernel 源码仓库都是以主线仓库（Mainline）为基础的。乍看之下，Linux Kernel 代码管理很像是 Monorepo 模式，所有东西都被收纳在由 Linus Torvalds 维护的 Mainline 仓库当中。 Linux Kernel 虽然为所有内容提供一套作为共享命名空间的单一文件层级结构，但出于不同应用需求与关注重点，各 repo 又保持着相互独立。换言之，Linux 内核项目更像是个由众多 repo 构成的 Monotree，而非 Monorepo。

Mainline

??Mainline 这个仓库是由 Linus Torvalds 本尊亲自维护的。它是所有新特性被引入到最终发布的 Linux Kernel 的地方。该仓库的官方地址是：https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git。此外，该仓库还在 Github 上做了一个镜像仓库：https://github.com/torvalds/linux。

1. Mainline 仓库就相当于我们开发中的主干分支。
2. 国内源：http://kernel.source.codeaurora.cn/pub/scm/linux/kernel/git/torvalds/linux.git
3. 几乎没有人是直接基于 Mainline 仓库进行开发的

??Mainline 仓库只有一个 master 分支，就相当于一棵树的主干，代表着 Linux Kernel 的发展方向。只有 Linus Torvalds 有权限在 Mainline 仓库中合并代码。Mainline 仓库是在不断发展的（周期性不断增加新功能），也因此，Mainline 仓库不需要额外的分支。对于每个达到发布要求的版本，Linus 本人就会采用打 tag 的方式进行发布，发布周期通常是 9 ~ 10 周。

??Mainline 发布版本号采用 a.b 格式。一般在发布一个正式版本之前，都会先发布一系列的候选（Release Candidate， 简称 RC）版本，其中的 Release Candidate 版本则使用从 a.b-rc1 开始往后排，直到达到发布条件后定版 a.b。比如 v5.18 最终版发布之前先发布了 v5.18-rc1 到 v5.18-rc8 共计 8 个 RC 版本。

??在 Linux 1.0 之前，采用是的是 0.xx 格式的版本号，在 1.0 ~ 2.6.11 期间采用的是语义化版本号 a.b.c 格式，在 2.6.11 ~ 2.6.39 期间采用了 a.b.c.d 的格式，3.0 之后又回归了语义化版本号 a.b.c 格式。在 a.b.c 格式中，x 为主版本号，y 为次版本号，z 为修订号。主版本号 a 的升级通常包含重大改变，次版本号 b 的升级既包括新特性引入，也包括缺陷修订（Bugfix），修订号 c 的升级只包括 Bugfix。

??某一个正式版和下一个候选版之间的时期叫做合并窗口期，比如，5.17 至 5.18-rc1 之间就是 5.18 版本的合并窗口期。这个合并窗口期大约是 2 周左右。只有在合并窗口期里才允许增加新特性，后续阶段（ RC 版本）只允许缺陷修订（Bugfix）。

Andrew Morton 在 linux-kernel 邮件列表中写的关于内核版本的内容：
??没有人知道内核何时发布，因为它是根据感知到的错误状态发布的，而不是根据先入为主的时间线发布的。

??由于 Mainline 仓库是在周期性不断增加新特性，新特性往往意味着更多的 BUG，尽管在 RC 阶段，Mainline 仓库的 Kernel 会重点关注于问题的修复，但是仍然不能保证 Mainline 仓库的 Kernel 稳定性可能并不是很好。除非开发者确实想要提前体验一些新的特性，否则不建议使用 Mainline 仓库的 Kernel。

Linux-stable

??Linux-stable 仓库用于跟踪已经发布的 Linux Kernel 版本，进行各种 BUG 的修复。其主要维护者是 Linux 社区的第二大人物 Greg Kroah-Hartman。该仓库的官方位置是 https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/。同样，该仓库也在 Github 上建立了一个镜像仓库：https://github.com/gregkh/linux。

1. Linux-stable 仓库就相当于我们开发中的 Release 分支。
2. 国内源：http://kernel.source.codeaurora.cn/pub/scm/linux/kernel/git/stable/linux.git

??当 Linus Torvalds 在其维护的 Mainline 仓库中发布了一个新的版本后（即 Mainline 仓库中新建 Tag（ 例如 5.17 ）后），紧接着他就会从 Mainline 仓库的 master 分支上 pull 一份到 Linux-stable 的 master 分支，同时 checkout 出来一个基于当前最新 master 分支（例如，5.17）的新分支（例如 linux-5.17.y）。分支名字采用在 Mainline 发布的版本号后加一个 .y 表示。其中的 .y 是作为错误修复发布的占位符。

??后续，新建的分支（例如， linux-5.17.y）将交给由 Greg Kroah-Hartman 领导的稳定分支维护团队进行维护，修复各种问题，在最终达到发布条件时，通过在分支上新建 Tag 的方式发布。由于 Linux-stable 对每个发布版本都需要进行各种问题的修复，因此，不能只使用 Tags，必须配合相应的分支才可以。每个分支就相当于稳定版的开发主干，每个分支上的 Tag 就是一个对外发布的稳定版。通过 Branch + Tag 这样的方式，就可以维护及发布多个不同的稳定版了。

??稳定版发布的版本号进一步扩展 Mainline 发布的版本号格式为 a.b.c，其中的 a.b 就是 Mainline 发布的 a.b，c 则是在发布时从 1 开始往后增加（例如，v5.17.1）。后续继续修复，继续新建 Tag（例如，v5.17.2），修订版本不断增加，直到 Linus Torvalds 在其维护的 Mainline 仓库中发布下一个稳定版，Linux-stable 也紧接着开启下一个稳定分支。

1. Kernel 的版本号没有修订版本为 a.b.0 的版本
2. 根据需要发布，正常的发布时间约为两周，但如果没有紧迫的问题，则可以更长

??并不是每个发布的稳定版的 Kernel 都会被广泛使用，Kernel 的版本迭代速度还是挺快的。当一个稳定版本被发布之后，到下一个稳定版本发布之前，该稳定版本通常仅会包含几次修订。其中，有些稳定版（例如 5.15 版）会被标记为 LTS（Long Term Support），这些版本的 Kernel 会在相当长的一段时间内一直被维护（a.b.c 中的 c 会很大）。下表给出了一些 LTS 稳定版的发布日期及支持维护的结束日期。

??Linux 内核中的错误修复有相应的规则：稳定内核的任何 bug 修复都是从主线树反向移植的，合入 Stable 仓库对应分支的修复补丁必须已经提交到 Mainline 仓库。这意味着主线内核将始终具有比稳定树中更早发布的更新的错误修复。但是，Stable 仓库不会包含 Mainline 仓库中合并的新特性，因此，Stable 仓库往往更具稳定性。

关于一个补丁如何才能被合入 Stable 分支，官方文档：Everything you ever wanted to know about Linux -stable releases

??然而，提交到 Mainline 仓库的修复补丁到底能不能在已经发布的旧版上很好的工作也是个未知数（绝大部分是没问题的）。此外，针对已发布的旧版的集成测试是比较少的。因此，没有定量或定性指标可以用来明确地说哪个版本的内核更稳定！

大多数 Linux 用户运行的 Kernel 是由某个 Linux 发行版提供的定制版内核

Subsystem

??Linux Kernel 将源码划分为了一些相对独立的子系统，每个子系统都有专门的人员负责维护，各个子系统的仓库可以在 https://git.kernel.org 上找到。具体的维护者可以在 Kernel 源码目录下的 ./MAINTAINERS 文件中找到。更方便的网页版 https://docs.kernel.org/process/maintainers.html。

https://git.kernel.org 上的某些仓库貌似已经没有维护了或者说换人维护了

??子系统仓库通常会包含一个 next 分支，有些大型的子系统甚至单独建立一个 next 仓库，用于存放那些需要提交到 Linux-next 的补丁。此外，子系统维护人员反过来可以从其他维护人员那里获取补丁。例如，网络树是由网络设备驱动程序、无线网络等专用树中积累的补丁构建而成。

??绝大多数开发者所贡献的代码首先要接受子系统管理员（Maintainer）的审核（通过邮件列表进行），进而能进入某个特定的子系统仓库，然后会在 linux-next 中进行集成测试，最后，由子系统维护者将那些没问题的补丁提交给 Linus Torvalds ，并最终被合并到 Kernel 主分支。

Linux-next

??Linux-next 仓库用于存放那些希望在下一个 merge 窗口期被合入 Mainline 的补丁代码，主要由 Stephen Rothwell 维护。官方原始仓库地址是：https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git。

1. Linux-next 仓库就相当于我们开发中的 Develop 分支。
2. 国内源：http://kernel.source.codeaurora.cn/pub/scm/linux/kernel/git/next/linux-next.git
3. https://www.kernel.org/doc/man-pages/linux-next.html

??Linux Kernel 中的各个子系统每天都在进行更改，有些更改甚至是跨子系统的，在将子系统树中的更新合并到主线树之前，需要对它们进行集成测试。Linux-next 仓库就是用来处理这个集成测试的。该仓库几乎每天都会将所有子系统树拉入其中，通过这种方式，linux-next 给出了在下一个合并期间将进入主线内核的那些补丁的基本情况。

??Linux-next 每天都会从众多子系统树中重新构建，每个子系统树本身也是每天在变化的。所以 linux-next 是一个移动的目标，就像主线一样。但是，与主线不同，linux-next 没有一致或连贯的历史。每天的 linux-next 树都是一个全新的开始，具有独特且短暂的历史。

??Linux-next 包含最前沿的 Linux Kernel 特性，仓库几乎每天都会新建一个 Tag，命名规则是 next-年月日。该仓库已经成为内核开发过程中不可或缺的一部分，在给定的合并窗口期间合并的所有补丁都应该在合并窗口打开之前的某个时间真正进入 linux-next 仓库。

加入 Linux 社区

??Linux Kernel 至今还在使用邮件列表和补丁提交的开源协作方式。要加入 Linux 社区，就是了解 Linux Kernel 的协作开发模式、流程及各种规范，并严格遵守相关规定。

1. Linux 社区的新手村：https://kernelnewbies.org

??在多年的发展中，Linux 社区制定了一系列严格的规范，例如 源代码的编码规范、代码提交规范等等。Linux Kernel 官方文档 Working with the kernel development community 中有专门章节来详细介绍如何加入 Linux 社区。

邮件列表

??邮件列表里面包含了多个邮件地址，当用户发邮件给一个真实存在的邮件列表时，里面包含的邮件地址都能收到这封邮件。邮件列表是一种常见而实用的电子邮件应用功能，本质是通过一种简单的方法，实现群发邮件的功能：其他人都可以收到某人发送到邮件列表的邮件。

??订阅邮件列表并不是必须的。订阅邮件列表就相当于我们加入了一个群聊，在此邮箱中可以查看群聊消息（任何人发送到我们订阅的邮件列表的邮件）。可以直接使用该邮箱回复群聊消息（回复指定的邮件），但注意格式要求。如果不订阅，我们就无法查看到其他人的聊天内容（提交 PATCH 的邮件）了。

1. 管理员可以可以控制这个邮件列表的使用权限，是任何人都可以给这个邮件列表发信，还是只有这个列表包含的成员可以给它发信
2. 发信给一个邮件列表，收信人不会看到这个邮件列表里都有哪些成员

VGER.KERNEL.ORG

??VGER.KERNEL.ORG 是 Linux 邮件列表服务站点。页面上列出了目前已知的所有 Linux 子系统的邮件订阅地址，后台的邮件服务器 VGER’s Majordomo 负责处理我们的订阅。

1. Kernel.org 的最新消息，他们在新的 ??lists.linux.dev?? 域下运行的新邮件列表服务，后续 VGER.KERNEL.ORG 将迁移到 lists.linux.dev
2. Majordomo 已不在维护，目前版本是 1.94.5

??成为 Linux 开发者的第一步就是在 http://vger.kernel.org/vger-lists.html 这里找到自己要贡献的某个部分，然后订阅对应的邮件列表。订阅或者取消订阅非常简单，只需要向 majordomo@vger.kernel.org 发送特定内容的邮件即可。订阅服务器对订阅邮件的内容有严格的要求：

1. 必须是纯文本格式的邮件
2. 邮件内容长度不能超过 100000 个字符
3. 必须按照固定格式回复邮件内容，空格、换行符等等都是不允许的。貌似，目前 Majordomo 改进了，能处理一些异常情况。

??由于邮件列表内容非常多（linux-kernel 邮件列表每天都有 200 ~ 300 封邮件），建议单独采用一个邮箱来进行订阅。此外，有网友反应国内部分邮箱面对大量邮件可能会给屏蔽。我当初是专门申请了一个 Google 的 Gmail 来订阅相关邮件列表。以下是我订阅 linux-embedded 的整个过程：

1. 发送订阅请求。直接登陆自己的网页版邮箱，发送邮件即可。注意：默认网页端邮件是 HTML 格式，需要改成纯文本格式。
   
   1. 如果 PC 上有邮件客户端，直接点击 http://vger.kernel.org/vger-lists.html 上的 subscribe 就会自动打开邮件客户端。
   2. 很多邮箱都自带签名功能，订阅时选择不使用签名
   3. 邮件标题可有可无，VGER’s Majordomo 并不关注邮件的标题。如果要写，可以是 Subscribe 订阅的模块名，甚至直接写个 Hello。
   4. 邮件内容还可以直接带有邮箱：subscribe linux-kernel 你的邮箱。官方不推荐这种方式。
   5. 不要直接复制网页上的内容，复制的内容通常会是包含格式的富文本格式
   6. 不要使用 Foxmail 等客户端，他会更改邮件的编码格式，VGER’s Majordomo 不支持
2. 回复确认。如果订阅请求邮件没有问题，我们会收到 Majordomo@vger.kernel.org 的回复邮件，要求我们进行确认。回复的格式要求与订阅请求时一样的。
   
   1. 可能要很久（小时级别，顶多一天）才能收到 Majordomo@vger.kernel.org 的回复邮件，请耐心等待。不要一直发送订阅请求，否则后续将会收到很多要求确认的邮件
   2. VGER’s Majordomo 会回复两封邮件，先收到的那封（标题为 Majordomo results:我们订阅的邮件标题）是说收到了我们的订阅请求，第二封（标题为 Confirmation for subscribe 订阅的模块名）则包含了需要我们确认的内容。且两封邮件间隔时间也挺长。
   3. 邮件要以重新写一封的形式来回复，不是直接回复邮件
   4. 根据测试，如果使用了 HTML，VGER’s Majordomo 也会回复确认，只是邮件中会提示错误
3. 订阅成功。成功回复确认之后，Majordomo@vger.kernel.org 会再次回复两封订阅成功的邮件。第一封标题为 Welcome to 订阅的模块名，第二封标题为 Majordomo results。
   
   1. 可能要很久（小时级别，顶多一天）才能收到 Majordomo@vger.kernel.org 的回复邮件。且两封邮件间隔时间也挺长。
   2. 等待一段时间我们就会收到大量（部分 Linux 模块订阅比较少）订阅的邮件列表中的邮件了
4. 如果要取消订阅，只需要将邮件正文中的 subscribe 改为 unsubscribe，其他格式与订阅请求一模一样，发送即可。

其他邮件列表

??除了官方的 VGER.KERNEL.ORG 之外，还有一些其他的 Linux 邮件列表，lists.infradead.org 和 listman.redhat.com 也是常用的邮件列表。这些邮件列表里通常会有一些 VGER.KERNEL.ORG 没有的订阅列表。

1. lists.infradead.org 和 listman.redhat.com 支持在网页端订阅
2. 我没在上面订阅过，参考一位网友的订阅过程：https://blog.csdn.net/flyingnosky/article/details/100071996

邮件存档

??Linux Kernel 官方提供了 lore.kernel.org 用于存档所有的 Linux 协作开发往来邮件内容。但是 lore.kernel.org 上的存档并不全，每个独立的模块还可能在其他地方提供订阅邮件的存档（http://vger.kernel.org/vger-lists.html 列表中会有说明）。

??Linux 社区非常看重邮件存档，这也是开通新的邮件订阅服务 lists.linux.dev 的一个重要原因。通过邮件存档服务，我们可以看到几乎所有 Linux 协作开发的来往邮件内容，还可以在其中找到对应的 PATCH。

文档

??Kernel 的文档（源码目录/Documentation/*）使用的是 Sphinx 搭建的文档系统。Sphinx 是基于 Python 的，使用的是 reStructuredText 语言格式，文件扩展名通常是 .rst。Sphinx 文档系统使用 make 命令来生成发布的文档，可以生成 html、pdf 等格式。

??Kernel 文档在线托管地址是：https://docs.kernel.org/。在线版文档就是使用 Sphinx 基于 源码目录/Documentation/* 生成的 html 格式的文档，两者内容并没有区别。

提交 PATCH

??想要为 Linux Kernel 贡献自己的代码必须要严格遵守 Linux 社区的相关规范。这些规范在 Linux Kernel 官方文档 Working with the kernel development community 中有专门章节介绍来详细介绍。包括但不限于编码规范、邮件列表使用、PATCH 格式、邮件的格式等等。

??不要视图直接往 clone 的仓库推送代码，只有对应仓库的维护人员才有权限。前面不止一次说过，Linux Kernel 至今还在使用邮件列表和补丁提交的开源协作方式。基本流程如下图所示：

环境及工具

??工欲善其事必先利其器。Linux 的开发需要使用 Linux 环境，可以选择自己喜欢的任意 Linux 发行版（我这里使用的是 Ubuntu 22.04 LTS）。其他一些工具，例如，git、git-email、make、gcc 等根据自己的环境使用对应的命令进行安装即可。

1. Linux Kernel 使用 Git 管理代码，要求我们熟练使用 Git，因为很多操作都是使用 Git 命令。
2. 不要使用邮件客户端发送 PATCH，https://docs.kernel.org/process/email-clients.html 列出了一些客户端如何正确使用

??为了确保发送的 PATCH 格式不会出错，一般使用 Git 自身提供的命令 git send-email 来发送 PATCH。默认安装 Git 后（请先自行配置 Git 用户名和邮箱），并没有 send-email，需要单独进行安装（Ubuntu：sudo apt install git-email）。然后就是配置 git-email。我这里使用的是 Gmail。直接命令：nano ~/.gitconfig。

??此外，还要确保自己的邮箱开启了 SMTP 功能及相关权限，否则导致无法使用 git send-email 发送邮件。很多邮箱默认是不开启的，例如，我这里使用的 Gmail，需要修改如下设置才能使用（由于众所周知的原因，要访问 Gmail 需要特殊工具）：

??这里就有个问题，发送 PATCH 的邮箱（git send-email 配置的邮箱）、Git 配置的邮箱（Git 使用用户名和邮箱来标识代码的提交者）、订阅邮件列表使用的邮箱三者是不是必须要一致呢？答案是否定的。可以选择使用同一个邮箱，也可以没有任何关系。邮件列表前面已经说过了，一般肯定是单独使用一个邮箱，否则就将面临在大量的邮件查找与自己相关的内容。Git 配置的邮箱和发送 PATCH 的邮箱最好是使用一个。

??默认情况下，邮件的 BODY 中的 From: 行指定的信息将被记入永久更新日志中作为补丁的作者。如果 From: 行缺失，那么电子邮件 HEADER 中的 From: 行将用于确定更新日志中的补丁作者。维护者回复时的邮箱是发送 PATCH 的邮箱，他们不关心 Git 配置的邮箱。

选择 Kernel 源码

??接下来就是正确选择并获取 Kernel 源代码树。直接克隆 Linus Torvalds 的 Mainline 仓库是一个选择，但是，更多的情况是针对特定的子系统进行开发。大多数子系统维护人员都有他们自己的代码仓库，通常，查看 Kernel 源代码目录下的 MAINTAINERS 文件（或者在线文档 https://docs.kernel.org/process/maintainers.html）查找对应的仓库地址。

不要视图直接往 clone 的仓库推送代码，只有对应仓库的维护人员才有权限

??一些开发人员建议将 linux-next 作为未来开发的主要分支，linux-next 分支确实远远超出主干，并且更能代表新的改进将合并到主干。但是，linux-next 的波动性往往使它成为一个艰难的发展目标。正如 linux-next 树的维护者 Stephen Rothwell 所说：“linux-next 工作方式的一个缺点是，因为它每天都要重新创建，所以不能真正将任何要合并到其中的东西建立在它的基础上。”

修改代码

??接下来就是修改代码，然后提交修改。尽量保证每个 Commit 中的修改在逻辑功能上是独立的，一个 Commit 中包含多种类型的修改将导致 PATCH 不能独立。可以通过查看文件修改的文件的历史的方式，看看别人提交的格式：

??Commit 信息的格式有严格限制，具体参考源码目录下 Documentation/process/submitting-patches.rst 文件 或者直接查看在线文档 https://docs.kernel.org/process/submitting-patches.html。不符合 Commit 格式的 PATCH 可能会被直接忽略。以下是一个 Commit 模板的基本说明：

drivers: fix some error

Why I do these changes and how I do it.

Signed-off-by: My Name <my_email@gmail.com>

每一行都不要超过 75 个字符，过长的内容请自觉换行：

• 第 1 行： 用简短的文字说明这个 Commit 干了啥。格式是 子系统名: 修改说明（注意冒号后面有个空格）。
• 第 2 行： 空行
• 第 3 行： 详细说明为啥要作此修改以及如何修改的。可以有任意多行内容，每行不要超过 75 个字符。
• 第 4 行： 空行
• 第 5 行： 标签行，用于给补丁声明一些信息，格式是 tag: info（注意冒号后面有个空格）。多个标签时每个标签独占一行。常用的标签有：
  • Signed-off-by：表示补丁提交者有权提交补丁以包含在内核中。意味着作者是签署过内核开发者原创认证协议的，该协议可以在内核文档 SubmittingPatches 中找到。该标签时必须的，没有签署该协议的补丁是不会被主干接受的。
  • Acked-by： 表示另一个开发人员（通常是相关代码的维护者）的协议，该补丁适合包含在内核中。
  • Tested-by：声明该补丁是经过某工程师测试过的，且没有发现任何问题，可以正常工作。
  • Reviewed-by：指定的开发人员已经检查了补丁的正确性，请参阅文档 SubmittingPatches 中的审阅者声明。
  • Reported-by：说明该补丁修复的问题的提出者。
  • Cc：指定人员收到了补丁的副本，并有机会对其发表评论。

生成 PATCH

??保证每个补丁只解决一个问题。如果修改包含了很多的 Commit，则需要根据情况拆分为多个不同的 PATCH。注意，每个 PATCH 都必须经过了自己严格的测试，最基础的一点就是保证编译没有任何错误。如果 PATCH 经过了其他人的测试，在提交请务必添加 Tested-by 标签。

??生成 PATCH 就比较简单了，主要就是对于 git format-patch 命令的使用。这个需要根据自己的开发情况并配合 git format-patch 的各个参数来使用。如下是一个示例：

??其中的 --subject-prefix='PATCH' 是为邮件标题添加个前缀。由于维护者会收到大量的电子邮件，通常会在主题行前面加上个前缀，以使维护者可以很好的区分邮件。可选值有：

??接下来需要运行命令 ./scripts/checkpatch.pl 你的 PATCH 来检查自己的 PATCH 格式有没有问题，必须要做到 0 errors, 0 warnings。

发送 PATCH

??保证 PATCH 没有任何问题后，就可以把 PATCH 发送给上游维护者了。首先，通过运行命令 ./scripts/get_maintainer.pl -f 你的 patch 或者 ./scripts/get_maintainer.pl -f 你的修改的文件 就可以自动罗列出对应的维护人员以及对应的邮件列表。

??接下来直接使用 git send-email --to 收件人邮箱1,收件人邮箱2 --cc 抄送1,抄送2 your.patch 发送 PATCH 了。每封邮件只包含一个 PATCH，至少抄送一个相关的邮件列表，并且不要向不相关的列表发送邮件。一般情况是，邮件列表采用抄送（--cc），其他人员选择直接发送（--to），多个邮箱之间用逗号分隔。git send-email 会自动抄送给补丁中的 From: 、Signed-off-by: 给出的人员的邮件。

??然后等待邮件中收到相应的反馈了！收到了反馈之后，请耐心给出解释，如果确实存在问题，及时修改。最终没有问题，静待自己的 PATCH 被合并即可。

参考

1. https://blog.ffwll.ch/2017/08/github-why-cant-host-the-kernel.html
2. https://tinylab.org/linux-repo-intro/
3. https://blog.csdn.net/jasonactions/article/details/120776434
4. https://opensourceway.community/posts/contribute_to_community/how_to_participate_in_the_linux_community/
5. https://lwn.net/Articles/289013/
6. https://blog.csdn.net/jcf147/article/details/123719000
7. https://zhuanlan.zhihu.com/p/138315470
8. https://cloud.tencent.com/developer/article/1525774
9. https://blog.51cto.com/mirage1993/1912785

开发者涨薪指南

48位大咖的思考法则、工作方式、逻辑体系