自 2020 年 1 月發(fā)布 5.5 內(nèi)核之后，到現(xiàn)在已經(jīng)有近 87,000 個(gè) patch，來自于近 4600 名開發(fā)者，都被合并到 mainline 倉(cāng)庫中了。review 所有這些 patch 的工作，對(duì)于愿意花時(shí)間的內(nèi)核開發(fā)者來說也都是一項(xiàng)艱巨的任務(wù)，所以是否要接受合并 patch，這個(gè)決定權(quán)就被委托給了各個(gè)子系統(tǒng)的維護(hù)者（maintainer）來代理決定，他們每個(gè)人都對(duì)內(nèi)核中這一部分的改動(dòng)具有部分或者完整的決定權(quán)。

這些維護(hù)者們就被記錄在一個(gè)叫 MAINTAINERS 的文件中（當(dāng)然是這個(gè)名字）。但是，MAINTAINERS 文件也需要維護(hù)，它能很好地反映現(xiàn)實(shí)情況嗎？MAINTAINERS 文件的存在目的，并不僅僅是為了讓大家給維護(hù)者點(diǎn)贊。開發(fā)者們需要用它來確定該把 patch 發(fā)到哪里。

get_maintainer.pl 腳本通過查看這個(gè) patch 修改了的文件，就可以生成一系列郵件地址來發(fā)送 patch，從而讓這一過程變得更加自動(dòng)化。如果這個(gè)文件中有錯(cuò)誤信息的話，就可能會(huì)讓 patch 發(fā)送到錯(cuò)誤的地方去，所以我們需要這個(gè)文件能保持更新。

最近，編者收到 Jakub Kicinski 的建議，他認(rèn)為可以比較 一下 MAINTAINERS 中的各個(gè)條目和現(xiàn)實(shí)世界中的工作的吻合程度，應(yīng)該能得到一些線索。于是折騰了一會(huì)兒 Python 之后，我們就得到了一個(gè)新的分析腳本。

Digging into MAINTAINERS

統(tǒng)計(jì)下來，MAINTAINERS 文件中已經(jīng)列出了 2280 個(gè) "subsystems (子系統(tǒng))"。每一個(gè)子系統(tǒng)都包括一個(gè)它所涵蓋的文件和目錄列表。我們可以查看這些文件的 commit 信息來這個(gè)子系統(tǒng)中都有誰在進(jìn)行工作。

撰寫 patch 顯然屬于工作內(nèi)容之一，但其他活動(dòng)也得算，比如處理 patch (可以從 Signed-off-by tag 來得到這個(gè)信息) 或 review patch (根據(jù) Reviewed-by 或 Acked-by)。

我們犧牲了一些 CPU 挖礦的時(shí)間，得到了一個(gè)大概統(tǒng)計(jì)值，也就是各個(gè)子系統(tǒng)中明確列出的維護(hù)者最后一次在該子系統(tǒng)中實(shí)際做了有效工作的時(shí)間是什么時(shí)候。

對(duì)于那些想看細(xì)節(jié)的人來說，可以直接看這個(gè)完整結(jié)果（https://lwn.net/Articles/842419/）。

不過，我們可以縮小數(shù)據(jù)范圍，在這個(gè)文件中挑選出一些我們更感興趣的內(nèi)容。例如，有 367 個(gè)子系統(tǒng)在整個(gè) Git 歷史中都沒有維護(hù)者，或維護(hù)者從未出現(xiàn)過（沒有包括那些沒有文件的 "子系統(tǒng)"–見下文）。

在這些子系統(tǒng)中，很多已經(jīng)過了它本身的黃金時(shí)期，比如現(xiàn)在 3c59x 網(wǎng)卡維護(hù)者根本沒有多少工作可做。網(wǎng)絡(luò)開發(fā)人員也不會(huì)收到很多 ATM 的 patch 了，Palm Treo 也不需要有多少支持工作了，蘋果最近也很少發(fā)布基于 M68k 的系統(tǒng)了，Arm 軟驅(qū)(floppy drive)也沒有多少人還在使用了，S3 Savage 顯卡也不再是以前人們所必備的設(shè)備了。

這幾百項(xiàng)中，很多可能都代表著可以完全刪除的代碼。類似的結(jié)論也可以從另一個(gè)列表中得到 (https://lwn.net/Articles/842424/)，那個(gè)列表中都是沒有列出維護(hù)者的子系統(tǒng)。當(dāng)然，其中一些子系統(tǒng)本身也不太對(duì)頭，有一個(gè)子系統(tǒng)簡(jiǎn)單地命名為 "ABI/API"，指向了 linux-api 郵件列表。實(shí)際上有一個(gè)文件是與這個(gè) "子系統(tǒng) " 相關(guān)的，kernel/sys_ni.c，這個(gè)文件會(huì)對(duì)那些未實(shí)現(xiàn)的系統(tǒng)調(diào)用進(jìn)行處理。因此，這個(gè)條目的存在價(jià)值，是為了讓開發(fā)者在添加新的系統(tǒng)調(diào)用時(shí)會(huì)抄送 linux-api 郵件列表。

"Arm subarchitectures " 條目也是類似情況。一些無維護(hù)者的子系統(tǒng)，比如 framebuffer 層，可能后續(xù)會(huì)有人愿意接手從而復(fù)活。

reiserfs 文件系統(tǒng)缺乏維護(hù)者，但似乎仍有一些用戶。其他的子系統(tǒng)，比如 DECnet 或 Matrox framebuffer，可能最好的處理就是不去管它了（或干脆刪除掉）。

MAINTAINERS 文件中列出的一些 "子系統(tǒng)" 沒有任何文件需要修改。

一個(gè)有趣的例子是 "embedded Linux"，據(jù)說由 Paul Gortmaker、Matt Mackall 和 David Woodhouse 維護(hù)。鑒于嵌入式 Linux 的成功，我們都認(rèn)為他們的工作非常出色。"device number registry" 聲稱是有維護(hù)的，但這里只包含一個(gè)鏈接，指向一個(gè)不存在的網(wǎng)頁。

"disk geometry and partition handling" 這一條中的 URL 仍然有效，但這些網(wǎng)頁似乎已經(jīng)有十多年沒有更新了，可以看出最近 Zip 驅(qū)動(dòng)器的 geometry 并沒有什么進(jìn)展。

man page 這些手冊(cè)頁面倒是有積極維護(hù)的，但它們不在內(nèi)核代碼樹中。

Help needed

從目前的結(jié)果可以得出幾個(gè)結(jié)論。一個(gè)是很多內(nèi)核子系統(tǒng)現(xiàn)在并不是真的需要有人來維護(hù)，相反，其中一些可能需要被刪除掉。另一個(gè)結(jié)論是，也許 MAINTAINERS 文件本身需要清理一下。但還有一個(gè)有價(jià)值的問題，那就是從這些數(shù)據(jù)是否可以看出是否有一些子系統(tǒng)從新的維護(hù)者中獲益匪淺的呢？

為了回答這個(gè)問題，我們又花費(fèi)了一些本來可以用來挖礦的 CPU 時(shí)間，來尋找符合這些標(biāo)準(zhǔn)的子系統(tǒng)。

沒有列出維護(hù)者，或者所謂的維護(hù)者已經(jīng)在該子系統(tǒng)中至少 6 個(gè)月沒有活動(dòng)了。

自 2020 年 1 月發(fā)布 5.5 內(nèi)核以來，至少有 50 個(gè)提交跟這個(gè)子系統(tǒng)有關(guān)。

這個(gè)搜索的目的是找出那些仍在進(jìn)行某種活躍開發(fā)，但沒有活躍的、明確指定的子系統(tǒng)。

搜索結(jié)果可以分為幾類。有些 MAINTAINERS 的條目中包含了大量的文件，使得 commit 數(shù)量看起來比真實(shí)情況要多了不少。

例如，名為 "ASYNCHRONOUS TRANSFERS/TRANSFORMS (IOAT) API "的子系統(tǒng)跟 drivers/dma 下的所有文件都有關(guān)，"DMA GENERIC OFFLOAD ENGINE SUBSYSTEM" 也包含這些文件。

該子系統(tǒng)則由 Vinod Koul 積極維護(hù)。有兩個(gè)子系統(tǒng)屬于這一類，在下面的表格中，"Activity" 列表示維護(hù)者最后一次我們看到他的活動(dòng)時(shí)間（如果有的話），而 "Commits" 則顯示了自 5.5 以來影響到這個(gè)子系統(tǒng)的 commit 次數(shù)。

這些子系統(tǒng)或者不是一個(gè)單獨(dú)的實(shí)體(entity)，或者應(yīng)該減少其覆蓋的文件清單，要以符合現(xiàn)實(shí)情況。

還有一些子系統(tǒng)的維護(hù)者使用的是公司電子郵件別名。比如 "DIALOG SEMICONDUCTOR DRIVERS" 的維護(hù)者是 support.opensource@diasemi.com，這個(gè)地址顯然不會(huì)出現(xiàn)在任何實(shí)際的 patch commit 中。不過在該子系統(tǒng)內(nèi)看進(jìn)去的話，可以看到許多來自 diasemi.com 郵件地址的許多 review，所以該子系統(tǒng)不能說是真的沒人維護(hù)。

這個(gè)類別包含：

與之相關(guān)的是有些子系統(tǒng)的維護(hù)者信息是過時(shí)的，指定的維護(hù)者并不活躍，但往往是來自同一公司的其他人接替了他的工作，并承擔(dān)事實(shí)上的維護(hù)工作。

這些包括：

最后，還有一些子系統(tǒng)似乎真的缺少維護(hù)者，它們通常的 commit 是由其他的子系統(tǒng)維護(hù)者來合并，或者是通過少數(shù)幾個(gè)終極維護(hù)者來最終合入的。

它們是：

對(duì)于一直關(guān)注相關(guān)領(lǐng)域的人來說，上面的列表并不出乎預(yù)料。frameebuffer 子系統(tǒng)是一個(gè)已知有問題的領(lǐng)域，由于缺乏維護(hù)，"soft scrollback" 功能最近就被從 framebuffer 驅(qū)動(dòng)中移除了。

不少人仍然需要使用這段代碼，但它越來越難以與內(nèi)核的圖形驅(qū)動(dòng)集成起來使用，很少有人有興趣去深入研究它。事實(shí)上，I2C host driver 確實(shí)有一個(gè)事實(shí)上的維護(hù)者，它就是 Wolfram Sang，他也維護(hù)著 core I2C 子系統(tǒng)。他一直希望有人能幫助他維護(hù)這些驅(qū)動(dòng)程序，但似乎沒有人愿意幫助他，所以他在有時(shí)間的時(shí)候就也負(fù)責(zé)維護(hù)這些驅(qū)動(dòng)程序。

/proc 是一個(gè)有趣的例子，每個(gè)人都依賴它，但沒有人負(fù)責(zé)維護(hù)它。HMM 也很有趣，創(chuàng)建者當(dāng)初花了很多精力來把 HMM 功能合入 mainline，但現(xiàn)在似乎轉(zhuǎn)向去忙其他事情了。

以上這些地方，看起來都是有抱負(fù)的內(nèi)核開發(fā)者可以參與進(jìn)來提供幫助的地方。那么那些在 MAINTAINERS 文件中沒有記錄的子系統(tǒng)呢？如果我們用快速腳本來查找一下內(nèi)核樹中所有的未被 MAINTAINERS 文件包含的文件，我們得到的文件列表包含超過 2800 個(gè)文件。其中自然包括 MAINTAINERS 文件本身。其余的絕大多數(shù)都是 include/下的頭文件，其中大部分可能都有維護(hù)者，應(yīng)該添加到 MAINTAINER 文件中相應(yīng)的條目下。

不過令人沮喪的是，在 kernel/目錄下有 72 個(gè)文件沒有列出維護(hù)者。這當(dāng)然不是現(xiàn)實(shí)情況。SYSV IPC 代碼是沒有維護(hù)者的，這反映了它普遍不受歡迎。

其余大部分未維護(hù)的文件都在 tools/ 或 samples/ 目錄下。比較難找出來的是 MAINTAINERS 中號(hào)稱會(huì)包含的文件中，其實(shí)有一些并不是由指定的人維護(hù)的。這種情況經(jīng)常出現(xiàn)在那些指定包含整個(gè)目錄樹的條目中。例如，編者被列為需要處理 Documentation/目錄，但肯定不能說我真的是在 "維護(hù)" 這么多文件。類似的情況在內(nèi)核樹中很多地方都有。

如果有人希望從這些數(shù)據(jù)中得出一些整體性的結(jié)論，那么可能會(huì)是這些：MAINTAINERS 文件肯定有一些黑暗的角落，這些角落本身也可能需要一些維護(hù)（其中一些已經(jīng)在做了）。內(nèi)核中一些缺乏維護(hù)者的部分，仍然是可以使用的，而另一些則已經(jīng)過于古老都不需要維護(hù)了。不過，大多數(shù)情況下，內(nèi)核中的子系統(tǒng)都有指定的維護(hù)者，而且他們中的大多數(shù)人至少都在努力維護(hù)他們負(fù)責(zé)的代碼。The situation could be a lot worse。

責(zé)任編輯：lq