LWN：4.9 内核陪伴我们的这六年！

关注了就能看到更多这么棒的文章哦～

Six years with the 4.9 kernel

By Jonathan Corbet
January 12, 2023
DeepL assisted translation
https://lwn.net/Articles/919570/

1 月 7 日发布的 4.9.337 stable kernel 的 update，标志着一个时代的结束：因为已经超过 6 年的维护周期了，4.9.x 系列将不再会有任何 update 了。在当初 Linus Torvalds 发布 "最终" 版本并不再关注它之后，这个版本的 kernel 仍然有了许多改动；现在是时候看看这个内核生命中的 "stable" 阶段来了解其中有哪些信息可以给到我们。

在完成 4.9 版本发布的那个开发周期中，合入了 16214 个 non-merge changeset，由 1719 名开发者贡献（在当时是创纪录的），他们属于（至少）228 家公司。在 4.9 和 4.9.337 这个六年的过程里，又获得了 23,391 个 non-merge changeset，来自于为 503 家公司工作的 4037 名开发者。4.9.337 版本比 4.9 版本多了 11.4 万行代码。与其说这是内核开发寿命的结束，不如说 Torvalds 的最后一个版本实际上只是一个新的、更长的阶段的开始——至少对于这些 long-term-support kernel （长期支持内核）来说是这样的。

Contributors

4.9.x 的主要贡献者是：

虽然 Greg Kroah-Hartman 是贡献了最多 changeset 的人，但值得注意的是，其中 337 个其实都仅仅是为每个 stable 版本修改了版本号。因此，他出现在这个表格中其实是一个假象。当然，并不是说他在这个过程中没有发挥重要作用，下面会看到这一点。

4.9.x 的贡献者中最活跃的公司和组织如下

跟 4.9 版本的统计数字进行一下对比会看到有意思的信息。其中有许多相同的名字，但排序不同。为一个 mainline 版本工作的最大贡献者可能不是该版本发布后提供最多 fix 的。

Backports

stable 内核有个规则，在加入 stable update 之前必须要先合入 mainline，所以上面统计的大部分（或全部）patch 都是针对 mainline 开发的。将它们 backport 移植回到 4.9 是在此基础上的一个额外工作。这项工作可能是直接将一个 patch 给 apply 到不同的代码 tree 上就好，也可能是将其完全重写这种非常复杂的做法。不管怎么说，把超过 23000 个 patch 移植回不同的内核，显然有很多工作要做。

Srivatsa S. Bhat 提出了一种方法，希望能把这些工作隔离开。开发者将一个 patch 移植回旧内核，实质上就是重新进行一次 commit，因此必须在 patch 的 changelog 中添加一个 Signed-off-by 的 tag。stable 内核中的每个 patch 都包含了 mainline 中原始 patch 的 commit ID。利用这些信息，我们就可以对每一个 stable patch 进行检查，并识别出在这个 patch 被合并到 mainline 之后所添加的那些 Signed-off-by 的 tag。这些额外的 signoff 应该就代表了是谁进行了这次 backport 移植。

在 4.9.x 系列中，有 21,495 个 commit 已经添加了 Signed-off-by tag。没有这个 tag 的，可能是上述对版本号的改动，也可能是应该打 tag 但是被遗漏了的，还有可能（可能性很大）是被原作者自己进行移植的 patch。因此，我们得到的是一张并不完美、但足够清晰的结果：

大部分的 backport 工作显然是由两位 stable kernel 的维护者所完成的。Kroah-Hartman 和 Sasha Levin。有些情况下他们对同一个 patch 都进行了签名，导致百分比加起来超过了 100%。相比之下，其他人所做的工作就显得微不足道了，尤其是如果我们只看 patch 数量的话。不过，通常情况下，除了 stable kernel 维护者之外，其他开发者之所以要 backport 一个 patch，主要是因为这个 backport 会很困难。所以，虽然其他开发者 backport 的 patch 少得多，但其中许多 patch 基本上都是需要更多工作量的。

Bug reports

理论上，stable 版本中的每个 patch 都应该是 bug fix，这意味着一定有人发现并报告了一个 bug。但事实是，4.9.x 系列中只有 4236 个 commit 包括了一个 Reported-by 标签，仅占总数的 18%。所以大部分被 fix 的问题要么是通过其他方式发现的，要么是没有包含这个 tag。对于那些确实包括这种 tag 的 patch 进行分析，得到如下结果：

bug report 的来源显然分布非常广泛，前三名（都是机器人）只占总数的 25% 多。即便如此，很明显，寻找 bug 的机器人正在报出很多问题，希望能在我们的用户之前提前发现。

Bug introduction

还可以查看一下 4.9.x 中 fix 的这些 bug 都是来自哪里。可以进行一些处理，利用 4.9.x commit 中的 Fixes 标签来找到原始 commit，就能提示我们 bug 的引入时间。结果差不多是这样：

[4.9.x 的 fix]

不出所料，4.9 和 4.8 版本是 stable 更新中所 fix 的许多 bug 的来源，每个版本都有近 700 个。此外就是通常所说的长尾了，包括了自 Git 时代开始的 2.6.12 版本以来的所有版本。Git 历史上 4.10 之前的版本每个版本都出现了。其中 fix 最少的版本是 2.6.17，它发布于 2006 年，"只有" 22 个 fix。

不过，这并不是全貌。4.9.28、4.9.34、4.9.51、4.9.75、4.9.77、4.9.78、4.9.79、4.9.94、4.9.102、4.9.187、4.9.194、4.9.195、4.9.198、4.9.207、4.9.214、4.9.219、4.9.228、4.9.253、4.9.258、4.9.259、4.9.261、4.9.265、4.9.298、4.9.299 这些版本中每一个都包含了一个 commit，指向了一个后续的 Fixes tag，而 4.9.81 和 4.9.218 中有两个，4.9.310 则有三个。显然，每一个都表明了一个被引入 stable 内核并在后来被修复的 regression 事件。但即使是这样也不是全貌，可以看看这个：

[4.9.x 之后的 fix］

4.9 之后的每个版本都引入了必须在 stable 更新中 fix 的 bug，总共超过 1500 个 fix。对于 "stable" 内核来说，有这么多的 commit 引入了 bug，这有些太多了。我们也不要从最近发布的内核的较低数量来给出错误的判断。有可能是我们发布的版本中的 bug 确实越来越少，但更合理的解释是，该图右上角的空白区域只是代表尚未被发现和 fix 的 bug。

因此，4.9 stable 并不完美，并不是人们经常表扬它时所说的那么完美。然而，它已经足够好了，已经成为许多部署的系统的核心部分，包括数量巨大的安卓设备。4.9 内核系列证明了当开发社区下定决心的时候可以做到什么程度。它是许多用户可以依赖的基石，算是光荣退休了。

全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。

欢迎分享、转载及基于现有协议再创作～

长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～