自2020年1月发布5.5内核以来，来自近4,600名开发者的近87,000个补丁已被合并到主线存储库中。审查所有这些补丁的工作对于愿意花时间的内核开发人员来说也是一项艰巨的任务，所以是否接受合并的补丁，这个决定委托给每个子系统的维护者来代表决定，他们每个人都有对更改内核的这一部分的部分或全部决策权。这些维护者被记录在一个名为MAINTAINERS（当然是名字）的文件中。但是，还需要维护MAINTAINERS文件。是否很好地反映了现实？MAINTAINERS文件的目的不只是让大家对维护者竖起大拇指。开发人员需要它来确定将补丁发送到哪里。get_maintainer.pl脚本查看补丁修改的文件并生成电子邮件地址列表以将补丁发送到，从而使该过程更加自动化。如果这个文件中有错误信息，可能会导致补丁发送到错误的地方，所以我们需要这个文件保持更新。最近，编辑收到JakubKicinski的建议，他认为比较MAINTAINERS中的每个条目与现实世界的工作的契合度应该会提供一些线索。于是在用Python折腾了一阵子后，得到了一个新的分析脚本。深入MAINTAINERS统计，MAINTAINERS文件中列出了2280个“子系统子系统”。每个子系统都包含它所涵盖的文件和目录的列表。我们可以查看这些文件的提交，看看谁在处理这个子系统。编写补丁显然是工作的一部分，但其他活动也很重要，例如处理补丁（您可以从Signed-off-by选项卡中获取此信息）或审查补丁（根据Reviewed-by或Acked-by）。我们牺牲了一些CPU挖掘时间来获得大致的统计数据，以了解每个子系统中明确列出的维护者实际在该子系统中进行有用工作的时间。对于那些想查看详细信息的人，可以直接查看完整结果。不过，我们可以缩小数据范围，在这个文件中挑出一些我们比较感兴趣的东西。例如，有367个子系统在整个Git历史中要么没有维护者，要么从未有过维护者（没有文件的不包括在内——见下文）。这些子系统中的许多都已过时，例如3c59x网卡维护人员现在根本没有太多工作要做。Web开发人员不再获得很多ATM补丁，PalmTreo不需要太多支持工作，Apple最近发布了很少的基于M68k的系统，Arm软盘驱动器不再使用太多，S3Savage显卡不再是过去人们必备的设备。这数百个项目中的许多项目可能代表可以完全删除的代码。从另一个未列出维护者的子系统列表中可以得出类似的结论。当然，其中一些子系统本身并不完全正确，一个子系统被简单地命名为“ABI/API”并指向linux-api邮件列表。实际上有一个与这个子系统相关的文件：kernel/sys_ni.c，它处理未实现的系统调用。因此，这个条目的价值在于允许开发人员在添加新的系统调用时抄送linux-api邮件列表。“ARMSUBARCHITECTURES”条目也是如此。一些没有维护者的子系统，比如FrameBuffer层，可能会被后来愿意接手的人复活。ReiserFS文件系统缺少维护者，但似乎仍有一些用户。其他子系统，例如DECnet或MatroxFrameBuffer，可能最好单独放置（或干脆删除）。MAINTAINERS文件中列出的某些子系统没有任何要修改的文件。一个有趣的例子是“EMBEDDEDLINUX”，据说由PaulGortmaker、MattMackall和DavidWoodhouse维护。鉴于嵌入式Linux的成功，我们都认为他们做得很好。“DEVICENUMBERREGISTRY”声称要维护，但仅包含指向不存在页面的链接。“DISKGEOMETRYANDPARTITIONHANDLING”条目中的URL仍然有效，但页面似乎已经十多年没有更新了，而且Zip驱动器几何最近也没有太大进展。手册页得到积极维护，但它们不在内核树中。需要帮助从目前的结果可以得出几个结论。一是现在很多内核子系统并不真的需要有人来维护，相反，其中一些可能需要被删除。另一个结论是，也许MAINTAINERS文件本身需要清理一下。但是还有一个值得思考的问题，是否可以从这些数据中判断出是否有一些子系统从新的维护者那里受益匪浅？为了回答这个问题，我们花费了更多本可以用于挖掘CPU时间的资源来寻找满足这些条件的子系统：自2020年1月发布5.5内核以来，与该子系统相关的提交至少有50次。此搜索的目的是找到仍在进行某种活动开发但没有活动的、指定良好的子系统的子系统。搜索结果可以分为几类。一些MAINTAINERS条目包含大量文件，使得提交数量看起来比实际数量大得多。例如，名为“ASYNCHRONOUSTRANSFERS/TRANSFORMS(IOAT)API”的子系统与drivers/dma下的所有文件相关，“DMAGENERICOFFLOADENGINESUBSYSTEM”也包含这些文件。该子系统由VinodKoul积极维护。有两个子系统属于这一类，在下表中，“活动时间”列表示维护者最后一次活动的时间（如果有的话），“提交计数”显示自5.5以来的提交次数影响此子系统的提交次数：这些子系统要么不是一个单一的实体，要么应该减少它们涵盖的文件列表以符合实际情况。还有使用公司电子邮件别名的子系统维护者。例如，“DIALOGSEMICONDUCTORDRIVERS”的维护者是support.opensource@diasemi.com，这个地址显然没有出现在任何实际的补丁提交中。但是如果你深入这个子系统，你可以看到许多来自diasemi.com电子邮件地址的审计，所以不能说这个子系统真的没有维护。此类别包含：对于维护者信息已过时的子系统，指定的维护者不活跃，但往往由同一公司的其他人接管并进行事实上的维护。其中包括：最后，还有一些子系统看起来确实缺乏维护者，它们通常的提交被其他子系统维护者合并，或者最终被少数最终维护者合并。它们在这里：对于一直关注相关领域的人来说，上面的列表应该不足为奇。“FRAMEBUFFERLAYER”子系统是一个已知的问题区域，由于缺乏维护，“软回滚”功能最近已从FrameBuffer驱动程序中删除。许多人仍然需要使用这段代码，但与内核的图形驱动程序集成越来越困难，很少有人有兴趣深入研究。事实上，I2C主机驱动程序确实有一个事实上的维护者，它是WolframSang，他还维护着核心I2C子系统。他一直希望有人能帮他维护这些驱动，但似乎没有人愿意帮助他，所以他有时间就负责维护驱动。/proc是一个有趣的例子，每个人都依赖它，但没有人负责维护它。《HMM》也很有意思，创作者花了不少心思将HMM功能融入主线，但现在似乎忙于其他事情。这些似乎是有抱负的内核开发人员可以介入并提供帮助的地方。未记录在MAINTAINERS文件中的子系统怎么办？如果我们运行一个快速脚本来查找内核树中未包含在MAINTAINERS文件中的所有文件，我们将得到一个包含2800多个文件的列表。这自然包括MAINTAINERS文件本身。其余绝大多数是include/下的头文件，其中大部分可能有维护者，应添加到MAINTAINER文件中的相应条目下。令人沮丧的是，在kernel/目录中有72个文件没有列出维护者。这当然不是现实。“SYSVIPC”代码没有维护者，反映出它普遍不受欢迎。其余大部分未维护的文件位于tools/或samples/目录中。更难发现的是，有些MAINTAINERS号称包含的文件实际上并不是由指定的人维护的。指定整个目录树的条目通常就是这种情况。例如，编辑器被列为需要在Documentation/目录下工作，但肯定不能说我真的在“维护”那么多文档。类似的情况在内核树的很多地方都存在。如果有人希望从这些数据中得出一些整体结论，可能是这些：MAINTAINERS文件肯定有一些暗角，它们本身可能需要一些维护（其中一些已经完成）。缺少维护者的内核的某些部分仍然可用，而其他部分则太旧而无法维护。不过，在大多数情况下，内核中的子系统都有指定的维护者，而且他们中的大多数至少都在努力维护他们负责的代码。它也可能更糟。（和往常一样，生成上述表格的脚本可以在git://git.lwn.net/gitdm.git的gitdm存储库中找到）。
