江苏龙网

  1. 首页 > 资讯 > 资讯 > >

Linux|两个月新增 80 万行代码，Linux 内核为什么不会崩？

8 月初，当 Linux 5.8 RC 版本开放测试时，大多数的新闻都聚焦于它的大小，称其为“史上最大的内核版本” 。正如 Linus Torvalds 本人指出的那样，“尽管没有任何一件事情能脱颖而出……但 5.8 似乎是我们有史以来最大的发行版之一 。”
Linux|两个月新增 80 万行代码，Linux 内核为什么不会崩？
文章图片

确实，刚刚发布的 Linux 内核 5.8 RC 具有超过 14,000 个 commit，约 80 万行新代码以及大约 100 名新贡献者 。要知道，距离 5.7 正式版发布才仅仅过去了约 2 个月的时间 。Linux 内核维护者 Steven Rostedt 认为，5.8 之所以变得如此之大，很有可能是因为 COVID-19 疫情让很多人难以出门旅行，所有人都因此能够在这期间完成比平时更多的工作 。
Rostedt 表示，从一个经验丰富的 Linux 内核贡献者和维护者的角度来看，5.8 RC 发行版特别令人震惊的并不是它的大小，而是它的空前规模对于那些正在维护它的人来说却没有造成困扰，“我认为这是因为 Linux 具有比世界上任何软件项目都好的工作流程 。”
拥有最佳的工作流程意味着什么？对 Rostedt 而言，这归结为 Linux 内核开发人员随着时间的推移建立的一系列基本规则，以使他们能够持续不断地大规模、可靠地发展 Linux 内核项目 。Rostedt 站在一个 Linux 内核资深维护者的角度，为我们分享了庞大的 Linux 内核项目 30 年来是如何有条不紊地运转的 。
第一个关键因素是 Git
首先让我们从 Linux 项目的历史来看 。在该项目的早期（1991-2002年），人们只能直接将补丁发送给 Linus Torvalds 。准确地说，Linus 从项目的子维护者那里获取补丁，而这些子维护者从其他代码贡献者那里获取补丁 。随着 Linux 内核变得越来越大，代码越来越复杂，很快他们就发现，一切都变得很难扩展和跟踪，并且项目将始终面临合并不兼容代码的风险 。
Linux|两个月新增 80 万行代码，Linux 内核为什么不会崩？
文章图片

这导致 Linus 开始探索包括 BitKeeper 在内的各种版本管理工具 。BitKeeper 是一种最早的分布式版本管理的方法，其他的版本管理系统通常使用签出/修改/签入协议，而 BitKeeper 则向所有人提供整个仓库的副本，并允许开发人员将其变更发送出去以进行合并 。Linux 在 2002 年开始短暂地采用了 BitKeeper，但是由于其本身是一个专有软件，被认为不符合社区对开源工作的信念，于是该工具在 2005 年停止使用 。为了寻找替代品，Linus 消失了一段时间，并带着 git 回来了，后者成为了更强大的分布式版本管理系统，并且是管理流程的第一个重要实例化 。Git 的出现使 Linux 开发在今天依然运转良好 。
Rostedt 为我们列出了 Linux 内核工作流程中，围绕 Git 展开的七个重要基本原则 。
七大基本原则每次commit只能做一件事
Linux 的中心原则是，所有更改都必须分解为小步骤进行 —— 您的每个commit都只能做一件事 。这并不意味着每个 commit 都必须很小，比如对在数千个文件中使用的函数的API进行简单更改，可以使更改量很大，但仍然可以接受，因为它是针对某一项单一任务的更改 。通过始终遵循此原则，项目维护者可以更轻松地识别和隔离任何有问题的更改，而不影响其他的功能 。
commit 不能破坏构建
不仅应该将所有更改分解为尽可能小的变量，而且还不能破坏内核 。即每个步骤都必须完全起作用，并且不引起退化 。这就是为什么对函数原型的更改还必须更新调用它的每个文件，以防止构建中断的原因 。因此，每个步骤都必须作为一个独立的更改来工作，这将我们带到了下一点：
所有代码都是二等分的
如果在某个时候发现了错误，则需要知道是哪个更改导致了问题 。从本质上讲，二等分是一种操作，它使开发者可以找到所有发生错误的确切时间点 。
为此，请转到最后一个已知的工作 commit 所在的节点，并且已知第一个 commit 已损坏，然后在该点测试代码 。如果可行，则前进到下一个节点；如果不是，则返回更上层的节点 。这样一来，开发者就可以在十几次编译/测试中，从成千上万的可能 commit 中分离出导致问题出现的 commit。Git 甚至可以通过 git bisect 功能帮助自动化该过程 。
重要的是，这只有在开发者遵守以前的规则的情况下才能很好地起作用：每个 commit 仅做一件事 。否则，您将不知道是 commit 的许多更改中的哪一个导致了问题；如果 commit 破坏了构建让整个项目无法正常启动，同时等分线又恰好落在了该 commit 上，则您将不知道接下来是该往上一个节点测试还是往下一个节点测试，因为它们都有问题 。这意味着您永远都不应编写依赖于将来 commit 的 commit，例如：调用尚不存在的函数，或更改全局函数的参数而不更改同一 commit 中的所有调用者 。
永远不要 rebase 公共分支
Linux 项目工作流程不允许 rebase 他人使用的任何公共分支 。因为 rebase 这些公共分支后，已重新基准化的 commit 将不再与基于原存储库中的相同 commit 匹配 。在树的层次结构中，不是叶子的公共主干部分不能重新设置基准，否则将会破坏层次结构中的下游分支 。


推荐阅读


上一篇：Apple|iPad Air 4概念图曝光：iPad Pro设计风格 改用USB-C接口

下一篇：Apple|2020款iPhone SE价格起售价或在iPhone 12发布后不久降至349美元