• https://www.kernel.org/doc/html/v6.6/process/1.Intro.html

简介

1.1. 执行摘要

本节的其余部分涵盖了内核开发过程的范围以及开发人员及其雇主可能遇到的各种挫折。有许多原因说明为什么内核代码应该合并到官方（“主线”）内核中，包括自动提供给用户、社区以多种形式提供支持以及影响内核开发方向的能力。贡献给Linux内核的代码必须在GPL兼容许可证下提供。

开发过程的运作介绍了开发过程、内核发布周期以及合并窗口的机制。涵盖了补丁开发、审查和合并周期中的各个阶段。还讨论了一些工具和邮件列表。鼓励希望开始内核开发的开发人员首先追踪并修复错误作为初始练习。

早期规划涵盖了早期项目规划，重点是尽早地让开发社区参与其中。

编写正确的代码是关于编码过程的；讨论了其他开发人员遇到的一些陷阱。涵盖了补丁的一些要求，并介绍了一些可以帮助确保内核补丁正确的工具。

发布补丁讨论了发布补丁进行审查的过程。要受到开发社区的认真对待，补丁必须格式正确、描述清晰，并且必须发送到正确的位置。遵循本节的建议应有助于确保您的工作获得最佳可能的接待。

跟进讨论了发布补丁后发生的事情；在那时工作远未完成。与审查者合作是开发过程中至关重要的一部分；本节提供了一些建议，介绍了如何在这一重要阶段避免问题。开发人员被告诫不要假设当补丁合并到主线时工作就完成了。

高级主题介绍了一些“高级”主题：使用git管理补丁和审查他人发布的补丁。

获取更多信息通过指向有关内核开发更多信息来源的指针来结束文档。

1.2. 本文档内容

Linux内核，拥有800多万行代码和每个发布版本都有1000多名贡献者，是目前存在的最大、最活跃的自由软件项目之一。自1991年以来，这个内核已经发展成为一种最佳的操作系统组件，可以运行在口袋大小的数字音乐播放器、台式个人电脑、现存最大的超级计算机以及各种中间类型的系统上。它是一个强大、高效、可扩展的解决方案，几乎适用于任何情况。

随着Linux的增长，希望参与其开发的开发人员（和公司）的数量也在增加。硬件供应商希望确保Linux能够很好地支持他们的产品，使这些产品对Linux用户具有吸引力。嵌入式系统供应商将Linux作为集成产品的组成部分，希望Linux能够尽可能地功能强大和适合手头的任务。基于Linux的发行版和其他软件供应商对Linux内核的功能、性能和可靠性有明确的兴趣。而最终用户也经常希望改变Linux以使其更好地满足他们的需求。

Linux最吸引人的特点之一是它对这些开发人员是开放的；任何具备必要技能的人都可以改进Linux并影响其发展方向。专有产品无法提供这种开放性，这是自由软件过程的一个特征。但是，内核甚至比大多数其他自由软件项目更加开放。典型的三个月内核开发周期可能涉及1000多名开发人员，他们来自100多家不同的公司（或者根本不属于任何公司）。

与内核开发社区合作并不是特别困难。但是，尽管如此，许多潜在的贡献者在尝试进行内核工作时都遇到了困难。内核社区已经形成了自己独特的运作方式，使其能够在每天都有成千上万行代码被改变的环境中平稳运行（并产生高质量的产品）。因此，Linux内核开发过程与专有开发方法有很大的不同。

对于新开发人员来说，内核的开发过程可能显得陌生和令人生畏，但背后有充分的理由和丰富的经验。一个不理解内核社区运作方式的开发人员（或者更糟糕的是，试图蔑视或规避这些方式的开发人员）将会遇到令人沮丧的经历。开发社区虽然乐于帮助那些试图学习的人，但对那些不愿倾听或不关心开发过程的人却没有时间。

希望阅读本文档的人能够避免这种令人沮丧的经历。这里有很多材料，但阅读它所需的努力将很快得到回报。开发社区始终需要愿意帮助使内核更好的开发人员；以下的文字应该帮助您 - 或者您的员工 - 加入我们的社区。

1.3. 鸣谢

本文档由Jonathan Corbet编写，[email protected]。Johannes Berg、James Berry、Alex Chiang、Roland Dreier、Randy Dunlap、Jake Edge、Jiri Kosina、Matt Mackall、Arthur Marsh、Amanda McPherson、Andrew Morton、Andrew Price、Tsugikazu Shibata和Jochen Voß的评论对其进行了改进。

这项工作得到了Linux基金会的支持；特别感谢Amanda McPherson，她看到了这一努力的价值并使其成为现实。

1.4. 将代码合并到主线的重要性

一些公司和开发人员偶尔会想知道为什么他们应该费心学习如何与内核社区合作，并将他们的代码合并到主线内核（“主线”是由Linus Torvalds维护的内核，并被Linux发行版用作基础）。从短期来看，贡献代码似乎是一种可以避免的开支；似乎更容易将代码保持分离并直接支持用户。事实上，将代码保持分离（“out of tree”）是一种虚假的经济。

为了说明分离代码的成本，这里列举了内核开发过程的一些相关方面；这些大部分将在本文档的后面更详细地讨论。考虑到：

• 已合并到主线内核的代码对所有Linux用户都是可用的。它将自动出现在启用它的所有发行版上。无需驱动程序光盘、下载或支持多个发行版的多个版本；对于开发人员和用户来说，一切都很顺利。合并到主线解决了大量的发行和支持问题。

• 虽然内核开发人员努力维护与用户空间的稳定接口，但内部内核API不断变化。缺乏稳定的内部接口是一个故意的设计决定；它允许随时进行基本改进，并导致更高质量的代码。但这一政策的一个结果是，任何分离的代码如果要与新内核一起工作，就需要不断地维护。维护分离的代码需要大量的工作。

• 相反，已合并到主线的代码不需要这样的工作，因为有一个简单的规则要求进行API更改的任何开发人员也必须修复由于该更改而导致的任何代码。因此，已合并到主线的代码的维护成本要低得多。

• 此外，内核中的代码通常会得到其他开发人员的改进。让您的用户社区和客户改进您的产品可能会带来意想不到的结果。

• 内核代码经过审查，无论是在合并到主线之前还是之后。无论原始开发人员的技能有多强，这个审查过程总能找到改进代码的方法。审查经常发现严重的错误和安全问题。对于在封闭环境中开发的代码来说，这一点尤其真实；这样的代码会因外部开发人员的审查而受益。分离的代码是低质量的代码。

• 参与开发过程是您影响内核开发方向的方式。在一旁抱怨的用户会被听到，但积极的开发人员有更有力的发言权 - 并且有能力实施使内核更适合他们需求的改变。

• 当代码保持分离时，第三方可能会贡献一个类似功能的不同实现。如果发生这种情况，将您的代码合并将变得更加困难 - 甚至到了不可能的地步。然后，您将面临不愉快的选择，要么（1）永远维护一个非标准的功能分离代码，要么（2）放弃您的代码，并将您的用户迁移到内核中的版本。

• 贡献代码是使整个过程运作的基本行为。通过贡献您的代码，您可以为内核添加新功能，并提供对其他内核开发人员有用的功能和示例。如果您为Linux开发了代码（或者正在考虑这样做），显然您对这个平台的持续成功有兴趣；贡献代码是帮助确保这一成功的最佳方式之一。

上述所有推理都适用于任何分离的内核代码，包括以专有、仅二进制形式分发的代码。然而，在考虑任何形式的仅二进制内核代码分发之前，应考虑额外的因素，包括：

• 关于分发专有内核模块的法律问题至少是模糊的；相当多的内核版权持有者认为大多数仅二进制模块是内核的衍生产品，因此它们的分发违反了GNU通用公共许可证（下文将对此进行更多讨论）。作者不是律师，因此本文档中的任何内容都不可能被视为法律建议。封闭源模块的真实法律地位只能由法院来确定。但是，这些模块所面临的不确定性是存在的。

• 二进制模块极大地增加了调试内核问题的难度，以至于大多数内核开发人员甚至都不会尝试。因此，分发仅二进制模块将使您的用户更难从社区获得支持。

• 对于仅二进制模块的分发者来说，支持也更加困难，因为他们必须为每个发行版和每个他们希望支持的内核版本提供一个模块的版本。可能需要几十个版本的单个模块才能提供相当全面的覆盖范围，而您的用户将不得不在每次升级内核时单独升级您的模块。

• 关于代码审查的所有内容都同样适用于闭源代码。由于这些代码根本不可用，因此它们不可能经过社区的审查，并且毫无疑问会存在严重问题。

特别是嵌入式系统的制造商可能会倾向于忽视本节中所说的大部分内容，因为他们正在出货一个使用冻结内核版本的自包含产品，发布后不需要进行更多的开发。这种论点忽略了广泛的代码审查的价值以及允许您的用户为您的产品添加功能的价值。但是，这些产品也有有限的商业寿命，之后必须发布新版本。在那时，代码已合并到主线并得到良好维护的供应商将更有可能迅速为新产品做好准备。

1.5. 许可

代码是根据多种许可证贡献给Linux内核的，但所有代码都必须与GNU通用公共许可证第2版（GPLv2）兼容，这是覆盖内核分发的许可证。实际上，这意味着所有代码贡献要么受到GPLv2的覆盖（可选地，允许在GPL的后续版本下分发），要么受到三条款BSD许可证的覆盖。任何不受兼容许可证覆盖的贡献都不会被接受到内核中。

对于贡献给内核的代码，不需要（也不会要求）进行版权转让。合并到主线内核的所有代码都保留其原始所有权；因此，内核现在拥有数千名所有者。

这种所有权结构的一个含义是，任何试图更改内核许可证的尝试几乎肯定会失败。几乎没有实际情况可以获得所有版权持有者的同意（或者将他们的代码从内核中删除）。因此，特别是在可预见的未来，内核许可证迁移到GPL第3版的前景是不存在的。

所有贡献给内核的代码都必须合法地成为自由软件。因此，来自匿名（或化名）贡献者的代码将不会被接受。所有贡献者都必须对他们的代码“签名”，声明该代码可以在GPL下与内核一起分发。未经其所有者许可的代码，或者可能为内核带来与版权相关的问题的代码（例如缺乏适当保障的逆向工程努力产生的代码）都不能被贡献。

关于与版权相关问题的问题在Linux开发邮件列表上很常见。这类问题通常会得到不少答复，但应记住回答这些问题的人不是