Linux 内核维护者的真相与误解！

自 2020 年 1 月发布 5.5 内核之后，到现在已经有近 87,000 个补丁，来自于近 4600 名开发者，都被合并到主线仓库中了。审核所有这些补丁的工作，对于愿意花时间的内核开发者来说也都是一项艰巨的任务，所以是否要接受合并补丁，这个决定权就被委托给了各个子系统的维护者（maintainer）来代理决定，他们每个人都对内核中这一部分的改动具有部分或者完整的决定权。这些维护者们就被记录在一个叫 MAINTAINERS 的文件中（理所当然是这个名字）。但是，MAINTAINERS 文件也需要维护，它能很好地反映现实情况吗？

MAINTAINERS 文件的存在目的，并不仅仅是为了让大家给维护者点赞。开发者们需要用它来确定该把补丁发到哪里。get_maintainer.pl 脚本通过查看这个补丁修改的文件，就可以生成一系列邮件地址来发送补丁，从而让这一过程变得更加自动化。如果这个文件中有错误信息的话，就可能会让补丁发送到错误的地方去，所以我们需要这个文件能保持更新。最近，编者收到 Jakub Kicinski 的建议，他认为可以比较一下 MAINTAINERS 中的各个条目和现实世界中的工作的吻合程度，应该能得到一些线索。于是折腾了一会儿 Python 之后，我们就得到了一个新的分析脚本。

深入 MAINTAINERS

统计下来，MAINTAINERS 文件中已经列出了 2280 个 “子系统（subsystems ）”。每一个子系统都包括一个它所涵盖的文件和目录列表。我们可以查看这些文件的提交信息来了解这个子系统中都有谁在进行工作。撰写补丁显然属于工作内容之一，但其他活动也得算，比如处理补丁 (可以从 Signed-off-by 标签来得到这个信息) 或审核补丁 (根据 Reviewed-by 或 Acked-by)。我们牺牲了一些 CPU 挖矿的时间，得到了一个大概统计值，也就是各个子系统中明确列出的维护者最后一次在该子系统中实际做了有效工作的时间是什么时候。

对于那些想看细节的人来说，可以直接看这个完整结果。

不过，我们可以缩小数据范围，在这个文件中挑选出一些我们更感兴趣的内容。例如，有 367 个子系统在整个 Git 历史中都没有维护者，或维护者从未出现过（没有包括那些没有文件的子系统——见下文）。在这些子系统中，很多已经过了它本身的黄金时期，比如现在 3c59x 网卡维护者根本没有多少工作可做。网络开发人员也不会收到很多 ATM 的补丁了，Palm Treo 也不需要有多少支持工作了，苹果最近也很少发布基于 M68k 的系统了，Arm 软驱也没有多少人还在使用了，S3 Savage 显卡也不再是以前人们所必备的设备了。这几百项中，很多可能都代表着可以完全删除的代码。

类似的结论也可以从另一个列表中得到，那个列表中都是没有列出维护者的子系统。当然，其中一些子系统本身也不太对头，有一个子系统简单地命名为 “ABI/API”，指向了 linux-api 邮件列表。实际上有一个文件是与这个子系统相关的：kernel/sys_ni.c，这个文件会对那些未实现的系统调用进行处理。因此，这个条目的存在价值，是为了让开发者在添加新的系统调用时会抄送到 linux-api 邮件列表。“ARM SUBARCHITECTURES” 条目也是类似情况。

一些无维护者的子系统，比如 FrameBuffer 层，可能后续会有人愿意接手从而复活。ReiserFS 文件系统缺乏维护者，但似乎仍有一些用户。其他的子系统，比如 DECnet 或 Matrox FrameBuffer，可能最好的处理就是不去管它了（或干脆删除掉）。

MAINTAINERS 文件中列出的一些子系统没有任何文件需要修改。一个有趣的例子是 “EMBEDDED LINUX”，据说由 Paul Gortmaker、Matt Mackall 和 David Woodhouse 维护。鉴于嵌入式 Linux 的成功，我们都认为他们的工作非常出色。“DEVICE NUMBER REGISTRY” 声称是有维护的，但这里只包含一个链接，指向一个不存在的网页。“DISK GEOMETRY AND PARTITION HANDLING” 这一条中的 URL 仍然有效，但这些网页似乎已经有十多年没有更新了，可以看出最近 Zip 驱动器的 geometry 并没有什么进展。手册页面倒是有积极维护的，但它们不在内核代码树中。

需要帮助

从目前的结果可以得出几个结论。一个是很多内核子系统现在并不是真的需要有人来维护，相反，其中一些可能需要被删除掉。另一个结论是，也许 MAINTAINERS 文件本身需要清理一下。但还有一个有价值的问题，那就是从这些数据是否可以看出是否有一些子系统从新的维护者中获益匪浅的呢？为了回答这个问题，我们又花费了一些本来可以用来挖矿的 CPU 时间，来寻找符合这些标准的子系统：

• 没有列出维护者，或者所谓的维护者已经在该子系统中至少 6 个月没有活动了。

• 自 2020 年 1 月发布 5.5 内核以来，至少有 50 个提交跟这个子系统有关。

这个搜索的目的是找出那些仍在进行某种活跃开发，但没有活跃的、明确指定的子系统。搜索结果可以分为几类。

有些 MAINTAINERS 的条目中包含了大量的文件，使得提交数量看起来比真实情况要多了不少。例如，名为 “ASYNCHRONOUS TRANSFERS/TRANSFORMS (IOAT) API”的子系统跟 drivers/dma 下的所有文件都有关，“DMA GENERIC OFFLOAD ENGINE SUBSYSTEM” 也包含这些文件。该子系统则由 Vinod Koul 积极维护。有两个子系统属于这一类，在下面的表格中，“活跃时间” 列表示维护者最后一次我们看到他的活动时间（如果有的话），而 “提交数” 则显示了自 5.5 以来影响到这个子系统的提交次数：

这些子系统或者不是一个单独的实体（entity），或者应该减少其覆盖的文件清单，要以符合现实情况。

还有一些子系统的维护者使用的是公司电子邮件别名。比如 “DIALOG SEMICONDUCTOR DRIVERS” 的维护者是 support.opensource@diasemi.com，这个地址显然不会出现在任何实际的补丁提交中。不过在该子系统内看进去的话，可以看到许多来自 diasemi.com 邮件地址的许多审核，所以该子系统不能说是真的没人维护。这个类别包含：

与之相关的是有些子系统的维护者信息是过时的，指定的维护者并不活跃，但往往是来自同一公司的其他人接替了他的工作，并承担事实上的维护工作。这些包括：

最后，还有一些子系统似乎真的缺少维护者，它们通常的提交是由其他的子系统维护者来合并，或者是通过少数几个终极维护者来最终合入的。它们是：

对于一直关注相关领域的人来说，上面的列表并不出乎预料。“FRAMEBUFFER LAYER” 子系统是一个已知有问题的领域，由于缺乏维护，“软回滚”功能最近就被从 FrameBuffer 驱动中移除了。不少人仍然需要使用这段代码，但它越来越难以与内核的图形驱动集成起来使用，很少有人有兴趣去深入研究它。

事实上，I2C host driver 确实有一个事实上的维护者，它就是 Wolfram Sang，他也维护着 core I2C 子系统。他一直希望有人能帮助他维护这些驱动程序，但似乎没有人愿意帮助他，所以他在有时间的时候就也负责维护这些驱动程序。/proc 是一个有趣的例子，每个人都依赖它，但没有人负责维护它。“HMM” 也很有趣，创建者当初花了很多精力来把 HMM 功能合入主线，但现在似乎转向去忙其他事情了。

以上这些地方，看起来都是有抱负的内核开发者可以参与进来提供帮助的地方。

那么那些在 MAINTAINERS 文件中没有记录的子系统呢？如果我们用快速脚本来查找一下内核树中所有的未被 MAINTAINERS 文件包含的文件，我们得到的文件列表包含超过 2800 个文件。其中自然包括 MAINTAINERS 文件本身。其余的绝大多数都是 include/ 下的头文件，其中大部分可能都有维护者，应该添加到 MAINTAINER 文件中相应的条目下。不过令人沮丧的是，在 kernel/ 目录下有 72 个文件没有列出维护者。这当然不是现实情况。“SYSV IPC” 代码是没有维护者的，这反映了它普遍不受欢迎。其余大部分未维护的文件都在 tools/ 或 samples/ 目录下。

比较难找出来的是 MAINTAINERS 中号称会包含的文件中，其实有一些并不是由指定的人维护的。这种情况经常出现在那些指定包含整个目录树的条目中。例如，编者被列为需要处理 Documentation/ 目录，但肯定不能说我真的是在 “维护” 这么多文件。类似的情况在内核树中很多地方都有。

如果有人希望从这些数据中得出一些整体性的结论，那么可能会是这些：MAINTAINERS 文件肯定有一些黑暗的角落，这些角落本身也可能需要一些维护（其中一些已经在做了）。内核中一些缺乏维护者的部分，仍然是可以使用的，而另一些则已经过于古老都不需要维护了。不过，大多数情况下，内核中的子系统都有指定的维护者，而且他们中的大多数人至少都在努力维护他们负责的代码。情况也有可能会更糟。

（和往常一样，生成上述表格的脚本可以在 gitdm 仓库中找到，网址是 git://git.lwn.net/gitdm.git ）。