Linux内核文档：《如何参与Linux内核开发》

本文转载自Linux内核官网，由于官网加载非常卡，为了方便阅读特意转发到博客。

内容具有时效性，需要阅读最新版本的同学，可通过下面的链接跳转：

https://www.kernel.org/doc/html/latest/translations/zh_CN/process/index.html

译者：

英文版维护者： Greg Kroah-Hartman <greg@kroah.com>
中文版维护者： 李阳  Li Yang <leoyang.li@nxp.com>
中文版翻译者： 李阳  Li Yang <leoyang.li@nxp.com>
               时奎亮 Alex Shi <alex.shi@linux.alibaba.com>
中文版校译者:
               钟宇  TripleX Chung <xxx.phy@gmail.com>
               陈琦  Maggie Chen <chenqi@beyondsoft.com>
               王聪  Wang Cong <xiyou.wangcong@gmail.com>

如何参与Linux内核开发

这是一篇将如何参与Linux内核开发的相关问题一网打尽的终极秘笈。它将指导你 成为一名Linux内核开发者，并且学会如何同Linux内核开发社区合作。它尽可能不 包括任何关于内核编程的技术细节，但会给你指引一条获得这些知识的正确途径。

如果这篇文章中的任何内容不再适用，请给文末列出的文件维护者发送补丁。

入门

你想了解如何成为一名Linux内核开发者？或者老板吩咐你“给这个设备写个Linux 驱动程序”？这篇文章的目的就是教会你达成这些目标的全部诀窍，它将描述你需 要经过的流程以及给出如何同内核社区合作的一些提示。它还将试图解释内核社区 为何这样运作。

Linux内核大部分是由C语言写成的，一些体系结构相关的代码用到了汇编语言。要 参与内核开发，你必须精通C语言。除非你想为某个架构开发底层代码，否则你并 不需要了解（任何体系结构的）汇编语言。下面列举的书籍虽然不能替代扎实的C 语言教育和多年的开发经验，但如果需要的话，做为参考还是不错的：

  • “The C Programming Language” by Kernighan and Ritchie [Prentice Hall] 《C程序设计语言（第2版·新版）》（徐宝文 李志 译）[机械工业出版社]
  • “Practical C Programming” by Steve Oualline [O’Reilly] 《实用C语言编程（第三版）》（郭大海 译）[中国电力出版社]
  • “C: A Reference Manual” by Harbison and Steele [Prentice Hall] 《C语言参考手册（原书第5版）》（邱仲潘 等译）[机械工业出版社]

Linux内核使用GNU C和GNU工具链开发。虽然它遵循ISO C89标准，但也用到了一些 标准中没有定义的扩展。内核是自给自足的C环境，不依赖于标准C库的支持，所以 并不支持C标准中的部分定义。比如long long类型的大数除法和浮点运算就不允许 使用。有时候确实很难弄清楚内核对工具链的要求和它所使用的扩展，不幸的是目 前还没有明确的参考资料可以解释它们。请查阅gcc信息页（使用“info gcc”命令 显示）获得一些这方面信息。

请记住你是在学习怎么和已经存在的开发社区打交道。它由一群形形色色的人组成， 他们对代码、风格和过程有着很高的标准。这些标准是在长期实践中总结出来的， 适应于地理上分散的大型开发团队。它们已经被很好得整理成档，建议你在开发 之前尽可能多的学习这些标准，而不要期望别人来适应你或者你公司的行为方式。

法律问题

Linux内核源代码都是在GPL（通用公共许可证）的保护下发布的。要了解这种许可 的细节请查看源代码主目录下的COPYING文件。Linux内核许可准则和如何使用 SPDX https://spdx.org/ 标志符说明在这个文件中 Documentation/translations/zh_CN/process/license-rules.rst （博主注：见转载《Linux内核许可规则》）

如果你对它还有更深入问题请联系律师，而不要在Linux内核邮件组上提问。因为 邮件组里的人并不是律师，不要期望他们的话有法律效力。

对于GPL的常见问题和解答，请访问以下链接：
http://www.gnu.org/licenses/gpl-faq.html

文档

Linux内核代码中包含有大量的文档。这些文档对于学习如何与内核社区互动有着 不可估量的价值。当一个新的功能被加入内核，最好把解释如何使用这个功能的文 档也放进内核。当内核的改动导致面向用户空间的接口发生变化时，最好将相关信 息或手册页(manpages)的补丁发到mtk.manpages@gmail.com，以向手册页(manpages) 的维护者解释这些变化。

以下是内核代码中需要阅读的文档：

内核还拥有大量从代码自动生成或者从 ReStructuredText(ReST) 标记生成的文档， 比如这个文档，它包含内核内部API的全面介绍以及如何妥善处理加锁的规则。所有 这些文档都可以通过运行以下命令从内核代码中生成为PDF或HTML文档:

make pdfdocs
make htmldocs

ReST格式的文档会生成在 Documentation/output. 目录中。 它们也可以用下列命令生成 LaTeX 和 ePub 格式文档:

make latexdocs
make epubdocs

如何成为内核开发者

如果你对Linux内核开发一无所知，你应该访问“Linux内核新手”计划：

http://kernelnewbies.org

它拥有一个可以问各种最基本的内核开发问题的邮件列表（在提问之前一定要记得 查找已往的邮件，确认是否有人已经回答过相同的问题）。它还拥有一个可以获得 实时反馈的IRC聊天频道，以及大量对于学习Linux内核开发相当有帮助的文档。

网站简要介绍了源代码组织结构、子系统划分以及目前正在进行的项目（包括内核 中的和单独维护的）。它还提供了一些基本的帮助信息，比如如何编译内核和打补 丁。

如果你想加入内核开发社区并协助完成一些任务，却找不到从哪里开始，可以访问 “Linux内核房管员”计划：

http://kernelnewbies.org/KernelJanitors

这是极佳的起点。它提供一个相对简单的任务列表，列出内核代码中需要被重新 整理或者改正的地方。通过和负责这个计划的开发者们一同工作，你会学到将补丁 集成进内核的基本原理。如果还没有决定下一步要做什么的话，你还可能会得到方 向性的指点。

在真正动手修改内核代码之前，理解要修改的代码如何运作是必需的。要达到这个 目的，没什么办法比直接读代码更有效了（大多数花招都会有相应的注释），而且 一些特制的工具还可以提供帮助。例如，“Linux代码交叉引用”项目就是一个值得 特别推荐的帮助工具，它将源代码显示在有编目和索引的网页上。其中一个更新及 时的内核源码库，可以通过以下地址访问：

https://elixir.bootlin.com/

开发流程

目前Linux内核开发流程包括几个“主内核分支”和很多子系统相关的内核分支。这些分支包括：

  • Linus 的内核源码树
  • 多个主要版本的稳定版内核树
  • 子系统相关的内核树
  • linux-next 集成测试树

主线树

主线树是由Linus Torvalds 维护的。你可以在https://kernel.org 网站或者代码 库中下找到它。它的开发遵循以下步骤：

  • 每当一个新版本的内核被发布，为期两周的集成窗口将被打开。在这段时间里维护者可以向Linus提交大段的修改，通常这些修改已经被放到-mm内核中几个星期了。提交大量修改的首选方式是使用git工具（内核的代码版本管理工具，更多的信息可以在 http://git-scm.com/ 获取），不过使用普通补丁也是可以的。
  • 两个星期以后-rc1版本内核发布。之后只有不包含可能影响整个内核稳定性的新功能的补丁才可能被接受。请注意一个全新的驱动程序（或者文件系统）有可能在-rc1后被接受是因为这样的修改完全独立，不会影响其他的代码，所以没有造成内核退步的风险。在-rc1以后也可以用git向Linus提交补丁，不过所有的补丁需要同时被发送到相应的公众邮件列表以征询意见。
  • 当Linus认为当前的git源码树已经达到一个合理健全的状态足以发布供人测试时，一个新的-rc版本就会被发布。计划是每周都发布新的-rc版本。
  • 这个过程一直持续下去直到内核被认为达到足够稳定的状态，持续时间大概是 6个星期。

关于内核发布，值得一提的是Andrew Morton在linux-kernel邮件列表中如是说：

“没有人知道新内核何时会被发布，因为发布是根据已知bug的情况来决定的，而不是根据一个事先制定好的时间表。”

子系统特定树

各种内核子系统的维护者——以及许多内核子系统开发人员——在源代码库中公开了他们当前的开发状态。这样，其他人就可以看到内核的不同区域发生了什么。在开发速度很快的领域，可能会要求开发人员将提交的内容建立在这样的子系统内核树上，这样就避免了提交与其他已经进行的工作之间的冲突。

这些存储库中的大多数都是Git树，但是也有其他的scm在使用，或者补丁队列被发布为Quilt系列。这些子系统存储库的地址列在MAINTAINERS文件中。其中许多可以在 https://git.kernel.org/上浏览。

在将一个建议的补丁提交到这样的子系统树之前，需要对它进行审查，审查主要发生在邮件列表上（请参见下面相应的部分）。对于几个内核子系统，这个审查过程是通过工具补丁跟踪的。Patchwork提供了一个Web界面，显示补丁发布、对补丁的任何评论或修订，维护人员可以将补丁标记为正在审查、接受或拒绝。大多数补丁网站都列 在 https://patchwork.kernel.org/

Linux-next 集成测试树

在将子系统树的更新合并到主线树之前，需要对它们进行集成测试。为此，存在一个 特殊的测试存储库，其中几乎每天都会提取所有子系统树：

https://git.kernel.org/？p=linux/kernel/git/next/linux-next.git

通过这种方式，Linux-next 对下一个合并阶段将进入主线内核的内容给出了一个概要 展望。非常欢冒险的测试者运行测试Linux-next。

多个主要版本的稳定版内核树

由3个数字组成的内核版本号说明此内核是-stable版本。它们包含内核的相对较小且 至关重要的修补，这些修补针对安全性问题或者严重的内核退步。

这种版本的内核适用于那些期望获得最新的稳定版内核并且不想参与测试开发版或 者实验版的用户。

稳定版内核树版本由“稳定版”小组（邮件地址stable@vger.kernel.org）维护，一般 隔周发布新版本。

内核源码中的 Documentation/process/stable-kernel-rules.rst（博主注：见转载《所有你想知道的事情 - 关于linux稳定版发布》） 文件具体描述了可被稳定版内核接受的修改类型以及发布的流程。

报告bug

bugzilla.kernel.org是Linux内核开发者们用来跟踪内核Bug的网站。我们鼓励用 户在这个工具中报告找到的所有bug。如何使用内核bugzilla的细节请访问：

http://test.kernel.org/bugzilla/faq.html

内核源码主目录中的:ref:admin-guide/reporting-bugs.rst 文件里有一个很好的模板。它指导用户如何报告可能的内核bug以及需要提供哪些信息 来帮助内核开发者们找到问题的根源。

利用bug报告

练习内核开发技能的最好办法就是修改其他人报告的bug。你不光可以帮助内核变 得更加稳定，还可以学会如何解决实际问题从而提高自己的技能，并且让其他开发 者感受到你的存在。修改bug是赢得其他开发者赞誉的最好办法，因为并不是很多 人都喜欢浪费时间去修改别人报告的bug。

要尝试修改已知的bug，请访问 http://bugzilla.kernel.org 网址。

邮件列表

正如上面的文档所描述，大多数的骨干内核开发者都加入了Linux Kernel邮件列 表。如何订阅和退订列表的细节可以在这里找到：

http://vger.kernel.org/vger-lists.html#linux-kernel

网上很多地方都有这个邮件列表的存档(archive)。可以使用搜索引擎来找到这些 存档。比如：

http://dir.gmane.org/gmane.linux.kernel

在发信之前，我们强烈建议你先在存档中搜索你想要讨论的问题。很多已经被详细 讨论过的问题只在邮件列表的存档中可以找到。

大多数内核子系统也有自己独立的邮件列表来协调各自的开发工作。从 MAINTAINERS文件中可以找到不同话题对应的邮件列表。

很多邮件列表架设在kernel.org服务器上。这些列表的信息可以在这里找到：

http://vger.kernel.org/vger-lists.html

在使用这些邮件列表时，请记住保持良好的行为习惯。下面的链接提供了与这些列 表（或任何其它邮件列表）交流的一些简单规则，虽然内容有点滥竽充数。

http://www.albion.com/netiquette/

当有很多人回复你的邮件时，邮件的抄送列表会变得很长。请不要将任何人从抄送 列表中删除，除非你有足够的理由这么做。也不要只回复到邮件列表。请习惯于同 一封邮件接收两次（一封来自发送者一封来自邮件列表），而不要试图通过添加一 些奇特的邮件头来解决这个问题，人们不会喜欢的。

记住保留你所回复内容的上下文和源头。在你回复邮件的顶部保留“某某某说到……” 这几行。将你的评论加在被引用的段落之间而不要放在邮件的顶部。

如果你在邮件中附带补丁，请确认它们是可以直接阅读的纯文本（如 Documentation/translations/zh_CN/process/submitting-patches.rst（博主注：见转载《如何让你的改动进入内核》）） 文档中所述）。内核开发者们不希望遇到附件或者被压缩了的补丁。只有这样才能 保证他们可以直接评论你的每行代码。请确保你使用的邮件发送程序不会修改空格 和制表符。一个防范性的测试方法是先将邮件发送给自己，然后自己尝试是否可以 顺利地打上收到的补丁。如果测试不成功，请调整或者更换你的邮件发送程序直到 它正确工作为止。

总而言之，请尊重其他的邮件列表订阅者。

同内核社区合作

内核社区的目标就是提供尽善尽美的内核。所以当你提交补丁期望被接受进内核的 时候，它的技术价值以及其他方面都将被评审。那么你可能会得到什么呢？

  • 批评
  • 评论
  • 要求修改
  • 要求证明修改的必要性
  • 沉默

要记住，这些是把补丁放进内核的正常情况。你必须学会听取对补丁的批评和评论， 从技术层面评估它们，然后要么重写你的补丁要么简明扼要地论证修改是不必要 的。如果你发的邮件没有得到任何回应，请过几天后再试一次，因为有时信件会湮 没在茫茫信海中。

你不应该做的事情：

  • 期望自己的补丁不受任何质疑就直接被接受
  • 翻脸
  • 忽略别人的评论
  • 没有按照别人的要求做任何修改就重新提交

在一个努力追寻最好技术方案的社区里，对于一个补丁有多少好处总会有不同的见解。你必须要抱着合作的态度，愿意改变自己的观点来适应内核的风格。或者至少愿意去证明你的想法是有价值的。记住，犯错误是允许的，只要你愿意朝着正确的方案去努力。

如果你的第一个补丁换来的是一堆修改建议，这是很正常的。这并不代表你的补丁不会被接受，也不意味着有人和你作对。你只需要改正所有提出的问题然后重新发送你的补丁。

内核社区和公司文化的差异

内核社区的工作模式同大多数传统公司开发队伍的工作模式并不相同。下面这些例 子，可以帮助你避免某些可能发生问题： 用这些话介绍你的修改提案会有好处：

  • 它同时解决了多个问题
  • 它删除了2000行代码
  • 这是补丁，它已经解释了我想要说明的
  • 我在5种不同的体系结构上测试过它……
  • 这是一系列小补丁用来……
  • 这个修改提高了普通机器的性能……

应该避免如下的说法：

  • 我们在AIX/ptx/Solaris就是这么做的，所以这么做肯定是好的……
  • 我做这行已经20年了，所以……
  • 为了我们公司赚钱考虑必须这么做
  • 这是我们的企业产品线所需要的
  • 这里是描述我观点的1000页设计文档
  • 这是一个5000行的补丁用来……
  • 我重写了现在乱七八糟的代码，这就是……
  • 我被规定了最后期限，所以这个补丁需要立刻被接受

另外一个内核社区与大部分传统公司的软件开发队伍不同的地方是无法面对面地交流。使用电子邮件和IRC聊天工具做为主要沟通工具的一个好处是性别和种族歧视将会更少。Linux内核的工作环境更能接受妇女和少数族群，因为每个人在别人眼里只是一个邮件地址。国际化也帮助了公平的实现，因为你无法通过姓名来判断人 的性别。男人有可能叫李丽，女人也有可能叫王刚。大多数在Linux内核上工作过并表达过看法的女性对在linux上工作的经历都给出了正面的评价。

对于一些不习惯使用英语的人来说，语言可能是一个引起问题的障碍。在邮件列表中要正确地表达想法必需良好地掌握语言，所以建议你在发送邮件之前最好检查一 下英文写得是否正确。

拆分修改

Linux内核社区并不喜欢一下接收大段的代码。修改需要被恰当地介绍、讨论并且拆分成独立的小段。这几乎完全和公司中的习惯背道而驰。你的想法应该在开发最开始的阶段就让大家知道，这样你就可以及时获得对你正在进行的开发的反馈。这样也会让社区觉得你是在和他们协作，而不是仅仅把他们当作倾销新功能的对象。无论如何，你不要一次性地向邮件列表发送50封信，你的补丁序列应该永远用不到这么多。

将补丁拆开的原因如下：

  • 小的补丁更有可能被接受，因为它们不需要太多的时间和精力去验证其正确性。一个5行的补丁，可能在维护者看了一眼以后就会被接受。而500行的补丁则需要数个小时来审查其正确性（所需时间随补丁大小增加大约呈指数级增长）。
    当出了问题的时候，小的补丁也会让调试变得非常容易。一个一个补丁地回溯 将会比仔细剖析一个被打上的大补丁（这个补丁破坏了其他东西）容易得多。

  • 不光发送小的补丁很重要，在提交之前重新编排、化简（或者仅仅重新排列）补丁也是很重要的。
    这里有内核开发者Al Viro打的一个比方：
    “想象一个老师正在给学生批改数学作业。老师并不希望看到学生为了得 到正确解法所进行的尝试和产生的错误。他希望看到的是最干净最优雅的 解答。好学生了解这点，绝不会把最终解决之前的中间方案提交上去。”
    内核开发也是这样。维护者和评审者不希望看到一个人在解决问题时的思 考过程。他们只希望看到简单和优雅的解决方案。

直接给出一流的解决方案，和社区一起协作讨论尚未完成的工作，这两者之间似乎 很难找到一个平衡点。所以最好尽早开始收集有利于你进行改进的反馈；同时也要 保证修改分成很多小块，这样在整个项目都准备好被包含进内核之前，其中的一部 分可能会先被接收。

必须了解这样做是不可接受的：试图将未完成的工作提交进内核，然后再找时间修复。

证明修改的必要性

除了将补丁拆成小块，很重要的一点是让Linux社区了解他们为什么需要这样修改。 你必须证明新功能是有人需要的并且是有用的。

记录修改

当你发送补丁的时候，需要特别留意邮件正文的内容。因为这里的信息将会做为补 丁的修改记录(ChangeLog)，会被一直保留以备大家查阅。它需要完全地描述补丁， 包括：

  • 为什么需要这个修改
  • 补丁的总体设计
  • 实现细节
  • 测试结果

想了解它具体应该看起来像什么，请查阅以下文档中的“ChangeLog”章节：

“The Perfect Patch” : http://www.ozlabs.org/~akpm/stuff/tpp.txt

这些事情有时候做起来很难。要在任何方面都做到完美可能需要好几年时间。这是 一个持续提高的过程，它需要大量的耐心和决心。只要不放弃，你一定可以做到。 很多人已经做到了，而他们都曾经和现在的你站在同样的起点上。

感谢

感谢Paolo Ciarrocchi允许“开发流程”部分基于他所写的文章 (http://www.kerneltravel.net/newbie/2.6-development_process)，感谢Randy Dunlap和Gerrit Huizenga完善了应该说和不该说的列表。感谢Pat Mochel, Hanna Linder, Randy Dunlap, Kay Sievers, Vojtech Pavlik, Jan Kara, Josh Boyer, Kees Cook, Andrew Morton, Andi Kleen, Vadim Lobanov, Jesper Juhl, Adrian Bunk, Keri Harris, Frans Pop, David A. Wheeler, Junio Hamano, Michael Kerrisk和Alex Shepard的评审、建议和贡献。没有他们的帮助，这篇文档是不可 能完成的。

英文版维护者： Greg Kroah-Hartman greg@kroah.com

posted @ 2020-01-04 14:30  广漠飘羽  阅读(495)  评论(0)  编辑  收藏  举报