Linus Torvalds 如期在 6 月 14 日发布了 7.1 内核。这一开发周期带来了大量新特性，同时也迎来了大批新开发者。现在是时候按照传统，来看看 7.1 的变更都来自何处，并顺便探讨一下我们的社区整体上可能正在发生怎样的变化。

本次发布合并了来自 2,479 名开发者的 15,849 个非合并变更集（changesets）。这使得 7.1 成为内核历史上最繁忙的开发周期之一；只有另外四个版本的提交（commits）数量超过了它。6.7 版本仍是有史以来最繁忙的，拥有 17,284 个提交，不过该版本的规模主要是由倒霉的 bcachefs 文件系统的加入及其全部开发历史所推动的。5.8、5.10 和 5.13 的提交数也多于 7.1，但领先优势要小得多。

参与 7.1 开发的开发者数量创下了新纪录，打破了 7.0 刚刚创下的 2,362 人的短暂纪录。这一趋势值得关注，但我们先从常规的数据看起。在 7.1 中贡献最频繁的开发者包括：

Johan Hovold [KSDB] 是本周期变更集的最大贡献者，他在 SPI 子系统及其他领域进行了大量的清理工作。Thomas Weißschuh [KSDB] 的工作涵盖了内核的许多部分，包括构建系统、nolibc、SPARC 架构代码等。Eric Biggers [KSDB] 一直在忙着重构内核的加密代码。Stefan Metzmacher [KSDB] 为 SMB 文件系统的实现做出了改进，而 Krzysztof Kozlowski [KSDB] 则继续在整个片上系统（SoC）和设备树（devicetree）子系统深耕。

在代码行数变动（lines-changed）列中，Jakub Kicinski [KSDB] 删除了大量陈旧且无人维护的网络代码，包括 ISDN、蓝牙 CMTP 和 ATM 子系统。Roman Li [KSDB] 引入了又一套庞大的 amdgpu 头文件。Namjae Jeon [KSDB] 带回了较旧的 NTFS 文件系统实现，并为其添加了许多新功能。Andrew Lunn [KSDB] 则删除了一批无人维护的网络驱动程序。

7.1 中有近 8% 的提交带有 Tested-by（测试者）标签，而近 51% 带有 Reviewed-by（审查者）标签。与最近的几个版本相比，这两个数字都相对较低。本次最顶尖的测试者和审查者是：

Daniel Wheeler [KSDB] 牢牢占据着内核头号署名测试者的常青树位置。在审查方面，Konrad Dybcio [KSDB] 为 334 个变更添加了标签，而 Dmitry Baryshkov [KSDB] 标记了 300 个；两人的审查几乎完全集中在高通（Qualcomm）驱动程序和设备树文件上，且大部分代码由他们的高通同事编写。

有 230 家我们能识别身份的雇主支持了 7.1 版本的开发；其中最活跃的是：

同往常一样，这部分与以往的开发周期相比几乎没有变化。

开发者源源不断而来

然而，有一件事正在发生明显的改变。在 7.0 开发统计文章中曾指出，首次贡献内核的人数一直在增长。7.1 周期延续了这一趋势，迎来了 530 名新贡献者 [KSDB]，远超 7.0 创下的 489 人的前纪录。现在的数字呈现出以下态势：

这种毫无停歇迹象的趋势，几乎可以肯定是由基于大语言模型（LLM）的开发工具日益普及所推动的；它已经在多个方面显现出影响。7.1 中有 299 个提交包含 Assisted-by（辅助者）标签，表明使用了此类工具。然而，实际有 LLM 参与创作的提交数量肯定要高得多；显然有很多开发者并没有遵守内核关于披露此类使用的规则。

这些新开发者出现在了一些令人意想不到的地方。例如，串行线路 IP（SLIP）协议的实现在过去多年里除了维护性变动外几乎无人问津，但现在却看到了来自 Weiming Shi [KSDB] 的修复，这位开发者最初是在 6.19 中崭露头角的。长期备受冷落的软盘驱动程序收到了来自 6.17 新人 Guangshuo Li [KSDB] 的修复（该修复随后被撤销）。OMFS 文件系统也迎来了多年来第一个非机械性的变更，由新人 HyungJung Joo [KSDB] 贡献。

7.1 中最高产的新人 Michael Bommarito [KSDB] 贡献了 60 个提交，其修复涵盖了 SMB 文件系统、SCTP 网络协议、蓝牙子系统、io_uring、SCSI 子系统、amdgpu 驱动程序、RDMA RoCEv2 实现等诸多领域。这些补丁几乎全部带有 Assisted-by 标签。很少有内核开发者能跨越这么多内核子系统做出实质性的修改；一个此前从未涉足的人能够做到这一点，完全是件新鲜事。但无论是新开发者还是老开发者，是否真的能完全理解横跨如此多内核子系统的实质性补丁，则是另一个问题了。

此外，似乎无穷无尽的拼写错误修复如今已经演变成了一场不折不扣的洪涝。作为文档维护者，我欢迎这些变动，因为这是新开发者熟悉开发流程的一种方式，但我也试图鼓励开发者转向更具实质性的修改——可惜这一建议被采纳的次数远没有我希望的那么多。

当然，接触 LLM 并不是开发者加入我们社区的唯一原因。在此开发周期中出现的首次开发者中，至少有 132 人已经可以关联到具体的雇主。高通以 15 名新开发者领跑，AMD 雇佣了 14 名，谷歌有 12 名。总共有 51 公司雇佣了 7.1 的新一代开发者。

将 Rust 引入内核的众多初衷之一，就是希望能吸引更年轻的开发者加入社区。总共有 5 名新开发者（略低于 1%）触及了 Rust 文件（以“.rs”结尾的文件）。其中 3 名开发者贡献了单个且体量较小的补丁，一人为 binder 驱动添加了若干追踪点（tracepoints），还有一人（Eliot Courtney [KSDB]）贡献了 23 个提交，其中 19 个用于正在开发中的 NVIDIA GPU “nova” 驱动。因此，Rust 或许正在带来新开发者，但目前规模还不大。

总的来说，新开发者最常触及的领域包括：

这里有一些有趣的规律。有大批新开发者参与文档工作表面上看起来是件好事……但请参阅上文提到的“拼写错误修复”。修改 MAINTAINERS（维护者）文件的新人数量可能令人担忧；最近发生过一两起陌生开发者试图夺取某个子系统维护权的事件，其前景令人担忧，原因显而易见。在本次 cases 中，大约有一半的 MAINTAINERS 变更伴随着该新开发者提交的新驱动程序。还有几位此前从未见过的开发者出现并声称拥有某个现有子系统的维护权，但他们使用的是相关公司的电子邮件地址，乍一看似乎合情合理。与此同时，staging（暂存）树初衷就是为了让新开发者进入社区，现在看来它仍在发挥着这一作用。

一个格外引人注目的数字是向 SMB 文件系统做出贡献的新开发者人数。这些开发者并不是在修复拼写错误，相反，他们正在解决看起来很严重、甚至可能涉及安全性的漏洞。目前尚不清楚这些开发者是自己运行工具来查找漏洞，还是有某种组织在引导新开发者去解决这些漏洞。但显而易见的是，任何在重视安全的场合使用 SMB 的人，可能都需要在接下来的一段时间里更勤快地跟进内核更新。

正如本文第一部分的数据所示，内核的开发进程似乎正以其一贯的高速——甚至更快一点的速度——向前推进。但时代变了。新的开发工具加速了大批新开发者涌入社区。如果他们中有足够多的人选择留下来，用不了多久，内核社区的构成以及社区的运转方式都将发生实质性的改变。我们正生活在一个有趣的时代。