關于Linux內核維護者的那些真相與誤解

自 2020 年 1 月發(fā)布 5.5 內核之后，到現在已經有近 87，000 個 patch，來自于近 4600 名開發(fā)者，都被合并到 mainline 倉庫中了。review 所有這些 patch 的工作，對于愿意花時間的內核開發(fā)者來說也都是一項艱巨的任務，所以是否要接受合并 patch，這個決定權就被委托給了各個子系統(tǒng)的維護者（maintainer）來代理決定，他們每個人都對內核中這一部分的改動具有部分或者完整的決定權。這些維護者們就被記錄在一個叫 MAINTAINERS 的文件中（當然是這個名字）。

但是，MAINTAINERS 文件也需要維護，它能很好地反映現實情況嗎？MAINTAINERS 文件的存在目的，并不僅僅是為了讓大家給維護者點贊。開發(fā)者們需要用它來確定該把 patch 發(fā)到哪里。get_maintainer.pl 腳本通過查看這個 patch 修改了的文件，就可以生成一系列郵件地址來發(fā)送 patch，從而讓這一過程變得更加自動化。如果這個文件中有錯誤信息的話，就可能會讓 patch 發(fā)送到錯誤的地方去，所以我們需要這個文件能保持更新。最近，編者收到 Jakub Kicinski 的建議，他認為可以比較 一下 MAINTAINERS 中的各個條目和現實世界中的工作的吻合程度，應該能得到一些線索。于是折騰了一會兒 Python 之后，我們就得到了一個新的分析腳本。

Digging into MAINTAINERS

統(tǒng)計下來，MAINTAINERS 文件中已經列出了 2280 個 “subsystems （子系統(tǒng)）”。每一個子系統(tǒng)都包括一個它所涵蓋的文件和目錄列表。我們可以查看這些文件的 commit 信息來這個子系統(tǒng)中都有誰在進行工作。撰寫 patch 顯然屬于工作內容之一，但其他活動也得算，比如處理 patch （可以從 Signed-off-by tag 來得到這個信息） 或 review patch （根據 Reviewed-by 或 Acked-by）。我們犧牲了一些 CPU 挖礦的時間，得到了一個大概統(tǒng)計值，也就是各個子系統(tǒng)中明確列出的維護者最后一次在該子系統(tǒng)中實際做了有效工作的時間是什么時候。對于那些想看細節(jié)的人來說，可以直接看這個完整結果）。不過，我們可以縮小數據范圍，在這個文件中挑選出一些我們更感興趣的內容。例如，有 367 個子系統(tǒng)在整個 Git 歷史中都沒有維護者，或維護者從未出現過（沒有包括那些沒有文件的 “子系統(tǒng)”–見下文）。

在這些子系統(tǒng)中，很多已經過了它本身的黃金時期，比如現在 3c59x 網卡維護者根本沒有多少工作可做。網絡開發(fā)人員也不會收到很多 ATM 的 patch 了，Palm Treo 也不需要有多少支持工作了，蘋果最近也很少發(fā)布基于 M68k 的系統(tǒng)了，Arm 軟驅（floppy drive）也沒有多少人還在使用了，S3 Savage 顯卡也不再是以前人們所必備的設備了。這幾百項中，很多可能都代表著可以完全刪除的代碼。

類似的結論也可以從另一個列表中得到，那個列表中都是沒有列出維護者的子系統(tǒng)。當然，其中一些子系統(tǒng)本身也不太對頭，有一個子系統(tǒng)簡單地命名為 “ABI/API”，指向了 linux-api 郵件列表。實際上有一個文件是與這個 “子系統(tǒng) ” 相關的，kernel/sys_ni.c，這個文件會對那些未實現的系統(tǒng)調用進行處理。因此，這個條目的存在價值，是為了讓開發(fā)者在添加新的系統(tǒng)調用時會抄送 linux-api 郵件列表?！癆rm subarchitectures ” 條目也是類似情況。一些無維護者的子系統(tǒng)，比如 framebuffer 層，可能后續(xù)會有人愿意接手從而復活。reiserfs 文件系統(tǒng)缺乏維護者，但似乎仍有一些用戶。其他的子系統(tǒng)，比如 DECnet 或 Matrox framebuffer，可能最好的處理就是不去管它了（或干脆刪除掉）。MAINTAINERS 文件中列出的一些 “子系統(tǒng)” 沒有任何文件需要修改。一個有趣的例子是 “embedded Linux”，據說由 Paul Gortmaker、Matt Mackall 和 David Woodhouse 維護。鑒于嵌入式 Linux 的成功，我們都認為他們的工作非常出色?！癲evice number registry” 聲稱是有維護的，但這里只包含一個鏈接，指向一個不存在的網頁?！癲isk geometry and partition handling” 這一條中的 URL 仍然有效，但這些網頁似乎已經有十多年沒有更新了，可以看出最近 Zip 驅動器的 geometry 并沒有什么進展。man page 這些手冊頁面倒是有積極維護的，但它們不在內核代碼樹中。

Help needed

從目前的結果可以得出幾個結論。一個是很多內核子系統(tǒng)現在并不是真的需要有人來維護，相反，其中一些可能需要被刪除掉。另一個結論是，也許 MAINTAINERS 文件本身需要清理一下。但還有一個有價值的問題，那就是從這些數據是否可以看出是否有一些子系統(tǒng)從新的維護者中獲益匪淺的呢？為了回答這個問題，我們又花費了一些本來可以用來挖礦的 CPU 時間，來尋找符合這些標準的子系統(tǒng)。沒有列出維護者，或者所謂的維護者已經在該子系統(tǒng)中至少 6 個月沒有活動了。

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

這個搜索的目的是找出那些仍在進行某種活躍開發(fā)，但沒有活躍的、明確指定的子系統(tǒng)。搜索結果可以分為幾類。有些 MAINTAINERS 的條目中包含了大量的文件，使得 commit 數量看起來比真實情況要多了不少。例如，名為 “ASYNCHRONOUS TRANSFERS/TRANSFORMS （IOAT） API ”的子系統(tǒng)跟 drivers/dma 下的所有文件都有關，“DMA GENERIC OFFLOAD ENGINE SUBSYSTEM” 也包含這些文件。該子系統(tǒng)則由 Vinod Koul 積極維護。有兩個子系統(tǒng)屬于這一類，在下面的表格中，“Activity” 列表示維護者最后一次我們看到他的活動時間（如果有的話），而 “Commits” 則顯示了自 5.5 以來影響到這個子系統(tǒng)的 commit 次數。SubsystemActivityCommits

ASYNCHRONOUS TRANSFERS/TRANSFORMS （IOAT） API——536

HISILICON NETWORK SUBSYSTEM DRIVER2019-11-16258

這些子系統(tǒng)或者不是一個單獨的實體（entity），或者應該減少其覆蓋的文件清單，要以符合現實情況。還有一些子系統(tǒng)的維護者使用的是公司電子郵件別名。比如 “DIALOG SEMICONDUCTOR DRIVERS” 的維護者是 support.opensource@diasemi.com，這個地址顯然不會出現在任何實際的 patch commit 中。不過在該子系統(tǒng)內看進去的話，可以看到許多來自 diasemi.com 郵件地址的許多 review，所以該子系統(tǒng)不能說是真的沒人維護。這個類別包含：SubsystemActivityCommits

DIALOG SEMICONDUCTOR DRIVERS——120

QUALCOMM ATHEROS ATH9K WIRELESS DRIVER——65

WOLFSON MICROELECTRONICS DRIVERS——146

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

HISILICON NETWORK SUBSYSTEM 3 DRIVER （HNS3）2019-11-16234

HISILICON SECURITY ENGINE V2 DRIVER （SEC2）2020-06-1855

LINUX FOR POWER MACINTOSH2018-10-1971

MELLANOX ETHERNET INNOVA DRIVERS——93

MELLANOX MLX4 IB driver——70

OMAP HWMOD DATA2016-06-10102

QCOM AUDIO （ASoC） DRIVERS2018-05-21125

TEGRA I2C DRIVER2018-05-3056

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

ARM/UNIPHIER ARCHITECTURE——73

DRBD DRIVER2018-12-2051

FRAMEBUFFER LAYER——402

HMM - Heterogeneous Memory Management2020-05-1954

I2C SUBSYSTEM HOST DRIVERS——434

MARVELL MVNETA ETHERNET DRIVER2018-11-2365

MEDIA DRIVERS FOR RENESAS - VIN2019-10-1056

MUSB MULTIPOINT HIGH SPEED DUAL-ROLE CONTROLLER2020-06-2454

NFC SUBSYSTEM——72

PROC FILESYSTEM——171

PROC SYSCTL2020-06-0851

QLOGIC QLGE 10Gb ETHERNET DRIVER2019-10-0477

STAGING - REALTEK RTL8188EU DRIVERS2020-07-15121

STMMAC ETHERNET DRIVER2020-05-01174

UNIVERSAL FLASH STORAGE HOST CONTROLLER DRIVER——277

USB NETWORKING DRIVERS——119

X86 PLATFORM DRIVERS - ARCH——119

對于一直關注相關領域的人來說，上面的列表并不出乎預料。frameebuffer 子系統(tǒng)是一個已知有問題的領域，由于缺乏維護，“soft scrollback” 功能最近就被從 framebuffer 驅動中移除了。不少人仍然需要使用這段代碼，但它越來越難以與內核的圖形驅動集成起來使用，很少有人有興趣去深入研究它。事實上，I2C host driver 確實有一個事實上的維護者，它就是 Wolfram Sang，他也維護著 core I2C 子系統(tǒng)。他一直希望有人能幫助他維護這些驅動程序，但似乎沒有人愿意幫助他，所以他在有時間的時候就也負責維護這些驅動程序。/proc 是一個有趣的例子，每個人都依賴它，但沒有人負責維護它。HMM 也很有趣，創(chuàng)建者當初花了很多精力來把 HMM 功能合入 mainline，但現在似乎轉向去忙其他事情了。以上這些地方，看起來都是有抱負的內核開發(fā)者可以參與進來提供幫助的地方。

那么那些在 MAINTAINERS 文件中沒有記錄的子系統(tǒng)呢？如果我們用快速腳本來查找一下內核樹中所有的未被 MAINTAINERS 文件包含的文件，我們得到的文件列表包含超過 2800 個文件。其中自然包括 MAINTAINERS 文件本身。其余的絕大多數都是 include/下的頭文件，其中大部分可能都有維護者，應該添加到 MAINTAINER 文件中相應的條目下。不過令人沮喪的是，在 kernel/目錄下有 72 個文件沒有列出維護者。這當然不是現實情況。SYSV IPC 代碼是沒有維護者的，這反映了它普遍不受歡迎。其余大部分未維護的文件都在 tools/ 或 samples/ 目錄下。比較難找出來的是 MAINTAINERS 中號稱會包含的文件中，其實有一些并不是由指定的人維護的。這種情況經常出現在那些指定包含整個目錄樹的條目中。

例如，編者被列為需要處理 Documentation/目錄，但肯定不能說我真的是在 “維護” 這么多文件。類似的情況在內核樹中很多地方都有。如果有人希望從這些數據中得出一些整體性的結論，那么可能會是這些：MAINTAINERS 文件肯定有一些黑暗的角落，這些角落本身也可能需要一些維護（其中一些已經在做了）。內核中一些缺乏維護者的部分，仍然是可以使用的，而另一些則已經過于古老都不需要維護了。不過，大多數情況下，內核中的子系統(tǒng)都有指定的維護者，而且他們中的大多數人至少都在努力維護他們負責的代碼。

原文標題：Linux內核維護者真相與誤解！

文章出處：【微信公眾號：嵌入式ARM】歡迎添加關注！文章轉載請注明出處。

責任編輯：haq