1. 介绍¶
1.1. 执行摘要¶
本节的其余部分涵盖了内核开发过程的范围以及开发者及其雇主可能遇到的各种挫折。内核代码应合并到官方（“主线”）内核中有许多重要原因，包括自动提供给用户、多种形式的社区支持以及影响内核开发方向的能力。贡献给 Linux 内核的代码必须在 GPL 兼容的许可下提供。
开发流程如何运作介绍了开发流程、内核发布周期以及合并窗口的机制。涵盖了补丁开发、审查和合并周期的各个阶段。还讨论了一些工具和邮件列表。鼓励希望开始内核开发的开发者追踪并修复错误作为初步练习。
早期规划涵盖了项目早期规划，重点是尽快让开发社区参与进来。
编写正确的代码是关于编码过程的；讨论了其他开发者遇到的一些陷阱。涵盖了补丁的一些要求，并介绍了一些有助于确保内核补丁正确的工具。
发布补丁讨论了发布补丁以供审查的过程。要被开发社区认真对待，补丁必须格式正确、描述清晰，并且必须发送到正确的位置。遵循本节中的建议应有助于确保您的工作获得最佳的反响。
后续跟进涵盖了发布补丁后会发生什么；此时工作远未完成。与审阅者合作是开发过程中至关重要的一部分；本节提供了许多关于如何避免在此重要阶段出现问题的提示。开发者应注意，不要以为补丁合并到主线后工作就完成了。
高级主题介绍了几个“高级”主题：使用 git 管理补丁和审查他人发布的补丁。
更多信息以指向有关内核开发的更多信息来源的链接结束了本文档。
1.2. 本文档内容¶
Linux 内核拥有超过 800 万行代码，每次发布都有超过 1000 名贡献者，是现存最大、最活跃的自由软件项目之一。自 1991 年诞生以来，该内核已发展成为一个卓越的操作系统组件，运行在袖珍数字音乐播放器、台式电脑、现存最大的超级计算机以及介于两者之间的所有类型系统上。它是一种适用于几乎任何情况的健壮、高效且可伸缩的解决方案。
随着 Linux 的增长，希望参与其开发的开发者（和公司）数量也随之增加。硬件供应商希望确保 Linux 良好地支持其产品，从而使这些产品对 Linux 用户具有吸引力。嵌入式系统供应商将 Linux 用作集成产品中的组件，他们希望 Linux 尽可能强大且适合手头的任务。分销商和其他基于 Linux 开发产品的软件供应商对 Linux 内核的功能、性能和可靠性有着明确的兴趣。最终用户也常常希望更改 Linux 以使其更好地满足自身需求。
Linux 最引人注目的特性之一是它对这些开发者是开放的；任何具备所需技能的人都可以改进 Linux 并影响其开发方向。专有产品无法提供这种开放性，而这正是自由软件流程的特点。但即便如此，内核也比大多数其他自由软件项目更加开放。一个典型的三个月内核开发周期可能涉及为 100 多家不同公司（或不为任何公司）工作的 1000 多名开发者。
与内核开发社区合作并非特别困难。然而，尽管如此，许多潜在贡献者在尝试进行内核工作时仍遇到了困难。内核社区已经发展出自己独特的运作方式，使其能够在每天都有数千行代码发生变化的环境中顺利运行（并生产出高质量的产品）。因此，Linux 内核开发过程与专有开发方法大相径庭也就不足为奇了。
内核的开发过程对新开发者来说可能显得陌生和令人生畏，但其背后有充分的理由和扎实的经验。不了解内核社区运作方式（或者更糟的是，试图蔑视或规避它们）的开发者将会经历沮丧。开发社区虽然乐于帮助那些正在学习的人，但对那些不愿听取或不关心开发过程的人则几乎没有耐心。
希望阅读本文档的人能够避免这种令人沮丧的经历。这里有很多资料，但阅读它所付出的努力很快就会得到回报。开发社区总是需要开发者来帮助改进内核；以下文本应能帮助您——或为您工作的人——加入我们的社区。
1.3. 致谢¶
本文档由 Jonathan Corbet (corbet@lwn.net) 撰写。通过 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 发行版用作基础的内核）。短期来看，贡献代码可能看似一项可避免的开支；似乎直接将代码分开并直接支持用户会更容易。事实是，将代码分开（“脱离主线”）是一种虚假的节约。
为了说明脱离主线的代码所带来的成本，这里列举了内核开发过程中的几个相关方面；其中大部分将在本文档后面更详细地讨论。请考虑：
已合并到主线内核中的代码可供所有 Linux 用户使用。它将自动存在于所有启用它的发行版中。无需驱动程序磁盘、下载或支持多个发行版多个版本的麻烦；这对开发者和用户来说都一切正常。合并到主线解决了大量的分发和支持问题。
尽管内核开发者努力维护用户空间的稳定接口，但内部内核 API 却在不断变化。缺乏稳定的内部接口是一个故意的设计决策；它允许随时进行根本性改进并产生更高质量的代码。但这项政策的一个结果是，任何脱离主线的代码如果想与新内核一起工作，都需要持续的维护。维护脱离主线的代码需要大量工作才能使其持续运行。
相反，主线中的代码则不需要这项工作，因为有一个简单的规则要求任何进行 API 更改的开发者也必须修复因该更改而中断的任何代码。因此，已合并到主线中的代码维护成本显著降低。
除此之外，内核中的代码常常会得到其他开发者的改进。授权您的用户社区和客户改进您的产品可能会带来意想不到的结果。
内核代码在合并到主线之前和之后都会经过审查。无论原始开发者的技能多么强大，这个审查过程总是能找到改进代码的方法。审查常常能发现严重的错误和安全问题。对于在封闭环境中开发的代码尤其如此；这类代码将从外部开发者的审查中受益匪多。脱离主线的代码是质量较低的代码。
参与开发过程是您影响内核开发方向的方式。旁观者的抱怨会被听到，但活跃的开发者拥有更强的话语权——以及实施更改以使内核更好地满足其需求的能力。
当代码独立维护时，第三方贡献相似功能的另一种实现的可能始终存在。如果发生这种情况，您的代码将很难甚至不可能被合并。届时，您将面临令人不快的选择：(1) 无限期地在主线之外维护一个非标准功能，或者 (2) 放弃您的代码并将您的用户迁移到树内版本。
代码贡献是使整个过程得以运作的基本行动。通过贡献您的代码，您可以向内核添加新功能，并提供对其他内核开发者有用的功能和示例。如果您已经为 Linux 开发了代码（或正在考虑这样做），您显然对该平台的持续成功抱有兴趣；贡献代码是帮助确保这种成功的最佳方式之一。
上述所有论点适用于任何脱离主线的内核代码，包括以专有、纯二进制形式分发的代码。然而，在考虑任何形式的纯二进制内核代码分发之前，还应考虑其他因素。这些因素包括：
围绕专有内核模块分发的法律问题充其量是模糊不清的；相当多的内核版权所有者认为，大多数纯二进制模块是内核的派生产品，因此，它们的发布违反了 GNU 通用公共许可证（下文将详细说明）。本文作者并非律师，本文中的任何内容均不能被视为法律建议。闭源模块的真实法律地位只能由法院裁定。但无论如何，困扰这些模块的不确定性始终存在。
二进制模块极大地增加了调试内核问题的难度，以至于大多数内核开发者甚至不会尝试。因此，分发纯二进制模块将使您的用户更难获得社区支持。
对于纯二进制模块的分销商来说，支持也更加困难，他们必须为他们希望支持的每个发行版和每个内核版本提供一个模块版本。单个模块可能需要数十次构建才能提供相当全面的覆盖，并且您的用户每次升级内核时都必须单独升级您的模块。
上面关于代码审查的一切内容对闭源代码尤其适用。由于此代码根本不可用，因此它无法经过社区审查，并且无疑会存在严重问题。
特别是嵌入式系统的制造商，可能倾向于忽视本节中所述的许多内容，认为他们正在发布一个使用固定内核版本且发布后无需更多开发的独立产品。这种论点忽略了广泛代码审查的价值以及允许用户为您的产品添加功能的价值。但这些产品也有有限的商业寿命，之后必须发布新版本。届时，那些代码已在主线中并得到良好维护的供应商将更有利于快速将新产品推向市场。
1.5. 许可¶
代码以多种许可协议贡献给 Linux 内核，但所有代码都必须与 GNU 通用公共许可证（GPLv2）第 2 版兼容，该许可证涵盖了整个内核分发。实际上，这意味着所有代码贡献都受 GPLv2（可选地，包含允许在 GPL 后续版本下分发的语言）或三条款 BSD 许可的保护。任何不受兼容许可保护的贡献将不被内核接受。
贡献给内核的代码不需要（也不要求）进行版权转让。所有合并到主线内核中的代码都保留其原始所有权；因此，内核现在拥有数千个所有者。
这种所有权结构的一个含义是，任何试图更改内核许可的尝试几乎注定会失败。在实际场景中，很少有能获得所有版权所有者同意（或从内核中移除其代码）的情况。因此，特别是，在可预见的未来，没有迁移到 GPL 第 3 版的可能性。
所有贡献给内核的代码都必须是合法的自由软件。因此，不接受来自身份不明或匿名贡献者的代码。所有贡献者都必须对其代码“签字确认”，声明该代码可以在 GPL 下随内核分发。未经其所有者许可为自由软件的代码，或可能为内核带来版权相关问题（例如源自缺乏适当保护的反向工程工作的代码）的代码，不能贡献。
关于版权相关问题在 Linux 开发邮件列表中很常见。此类问题通常会得到大量的答案，但应牢记，回答这些问题的人不是律师，无法提供法律建议。如果您有与 Linux 源代码相关的法律问题，没有比与了解该领域的律师交谈更好的替代方案。依赖从技术邮件列表获得的答案是冒险的事情。