blog

意見|Linuxカーネルのメンテナに関する真実と誤解!

そして、その決定は個々のサブシステムのメンテナに委任され、代理で決定され、それぞれがカーネルのその部分に対する変更について部分的あるいは完全な決定権を持っています。...

Nov 3, 2025 · 8 min. read
シェア

徹底的なメンテナンス

全部で、MAINTAINERS ファイルには 2280 の "" がリストされています。各サブシステムには、対象となるファイルとディレクトリのリストが含まれています。これらのファイルのコミット情報を見ることで、そのサブシステムで誰が作業を行っているかを知ることができます。パッチの書き込みは明らかに作業の一部ですが、パッチの処理(Signed-off-by タブからこの情報を得ることができます)やパッチのレビュー(Reviewed-by や Acked-byによる)など、他の作業もカウントする必要があります。各サブシステムに明示的にリストされているメンテナが、最後にそのサブシステムで実際に有効な作業を行ったのはいつなのか、大まかな統計を取るために、CPU マイニングの時間を犠牲にしてください。

詳細をご覧になりたい方は、このご覧ください。

しかし、データを絞り込んでこのファイルから興味深い要素をいくつか選び出すことは可能です。例えば、 367のサブシステムで、Gitの全履歴においてメンテナが存在しないか、存在したことがないものがあります。これらのサブシステムの多くは全盛期を過ぎており、例えば 3c59x NIC のメンテナが今やるべき仕事はあまりありません。ネットワーク開発者は ATM のパッチをあまり受け取らなくなり、Palm Treo はあまりサポートを必要とせず、Apple は最近 M68k ベースのシステムをほとんどリリースせず、Arm フロッピードライブはもう多くの人に使われておらず、S3 Savage グラフィックカードはかつてのような必須デバイスではありません。これらの何百もの項目の多くは、おそらく完全に削除できるコードです。

同じような結論は別の367 サブシステム導き出せます。そのリストは、メンテナがリストされていないサブシステムでいっぱいです。あるサブシステムは単に "ABI/API "という名前で、linux-apiメーリングリストを指しています。あるサブシステムは単に "ABI/API "と名付けられ、linux-apiメーリングリストを指しています。このサブシステムに関連するファイルとして、未実装のシステムコールを処理するkernel/sys_ni.cがあります。そのため、このエントリーは、開発者が新しいシステムコールを追加するときに linux-api メーリングリストにコピーされるように、あらゆる目的で存在します。ARM SUBARCHITECTURES "エントリも同じような状況です。

また、ReiserFS ファイルシステムはメンテナを欠いていますが、 まだ何人かのユーザがいるようです。DECnetやMatrox FrameBufferのような他のサブシステムは、おそらく放っておくのが一番でしょう。

MAINTAINERS ファイルにリストされているサブシステムの中には、修正する必要のあるファイルがないものもあります。興味深い例は "EMBEDDED LINUX" で、Paul Gortmaker、Matt Mackall、David Woodhouse が保守していると言われています。組み込みLinuxの成功を考えると、彼らが素晴らしい仕事をしていることは誰もが認めるところです。"DEVICE NUMBER REGISTRY" は保守されていると主張されていますが、ここには存在しないウェブページへのリンクがあるだけです。"DISK GEOMETRY AND PARTITION HANDLING" このエントリのURLはまだ有効ですが、ページは10年以上更新されていないようで、最近Zipドライブのジオメトリにあまり進歩がないことがわかります。マニュアルのページは活発にメンテナンスされていますが、カーネルのコードツリーにはありません。

助けが必要です。

これまでの結果から導き出される結論はいくつかあります。ひとつは、多くのカーネルサブシステムは今すぐ誰かがメンテナンスする必要はないということです。もう一つの結論は、おそらくMAINTAINERSファイル自体を少し整理する必要があるということです。それは、このデータから、新しいメンテナから大きな恩恵を受けるサブシステムがあるかどうかを見分けることが可能かどうかということです。この質問に答えるために、採掘に費やすことができたはずのCPU時間を、これらの条件を満たすサブシステムを探すために費やしました:

  • メンテナーが記載されていないか、想定されるメンテナーがサブシステムで少なくとも6ヶ月間活動していません。

この検索の目的は、現在も何らかのアクティブな開発が行われているものの、アクティブで明確に指定されていないサブシステムを特定することです。検索結果はいくつかのカテゴリーに分けられます。

いくつかの MAINTAINERS エントリには多数のファイルが含まれているため、コミット数が実際よりも多く見えます。例えば、"ASYNCHRONOUS TRANSFERS/TRANSFORMS API" というサブシステムは、"drivers/dma" の下にあるすべてのファイルに関連付けられています。SUBSYSTEM "にもこれらのファイルが含まれています。このサブシステムはVinod Koulによって積極的に保守されています。このカテゴリーに分類されるサブシステムは2つあります。 以下の表では、"Active time "列はメンテナが最後にアクティブになった時期を示し、"Commits "列は5.5以降にこのサブシステムに影響を与えたコミット数を示しています:

ASYNCHRONOUS TRANSFERS/TRANSFORMS API -- 635
HISILICON NETWORK SUBSYSTEM DRIVER 852

これらのサブシステムは1つではないか、現実に合うように対象文書のリストを減らすべきです。

また、メンテナが会社の電子メールエイリアスを使用しているサブシステムもあります。例えば、"DIALOG SEMICONDUCTOR DRIVERS" は support.opensource@diasemi.comによってメンテナンスされています。しかし、そのサブシステムの内部を見ると、diasemi.com の電子メールアドレスからのレビューがたくさんあるので、そのサブシステムはメンテナンスされていないとは言えません。このカテゴリには

DIALOG SEMICONDUCTOR DRIVERS -- 021
qualcomm atheros ath9k wireless driver -- 65
WOLFSON MICROELECTRONICS DRIVERS -- 641

これに関連して、いくつかのサブシステムではメンテナ情報が古く、指定されたメンテナが活動していないにもかかわらず、同じ会社の他の誰かが引き継いで事実上の保守を引き受けていることがよくあります。これには以下が含まれます:

HISILICON NETWORK SUBSYSTEM 3 DRIVER 432
HISILICON SECURITY ENGINE V2 DRIVER 55
LINUX FOR POWER MACINTOSH 71
MELLANOX ETHERNET INNOVA DRIVERS -- 93
MELLANOX MLX4 IB driver -- 70
OMAP HWMOD DATA 201
QCOM AUDIO DRIVERS 521
TEGRA I2C DRIVER 56

最後に、メンテナーが本当に不足していると思われるサブシステムがいくつかあり、それらの通常のコミットは他のサブシステムのメンテナーによってマージされるか、最終的には数人の最終的なメンテナーを通してマージされます。それらは以下のようなものです:

ARM/UNIPHIER ARCHITECTURE -- 73
DRBD DRIVER 51
FRAMEBUFFER LAYER -- 204
HMM - Heterogeneous Memory Management 54
I2C SUBSYSTEM HOST DRIVERS -- 434
MARVELL MVNETA ETHERNET DRIVER 65
WOLFSON MICROELECTRONICS DRIVERS 56
ARM/UNIPHIER ARCHITECTURE 54
I2C SUBSYSTEM HOST DRIVERS -- 72
PROC FILESYSTEM -- 171
PROC SYSCTL 51
QLOGIC QLGE 10Gb ETHERNET DRIVER 77
STAGING - REALTEK RTL8188EU DRIVERS 121
STMMAC ETHERNET DRIVER 471
UNIVERSAL FLASH STORAGE HOST CONTROLLER DRIVER -- 772
USB NETWORKING DRIVERS -- 911
X86 PLATFORM DRIVERS - ARCH -- 911

I2Cホスト・ドライバには、コアI2Cサブシステムも保守しているWolfram Sangという事実上のメンテナがいます。彼は、誰かがこれらのドライバの保守を手伝ってくれることを望んでいますが、誰もそれを望んでいないようなので、時間があるときに保守を引き受けています。/procは、誰もが依存しているにもかかわらず、誰もその保守に責任を持たないものの興味深い例です。"HMM "もまた、作成者がHMMの機能をメインラインにマージすることに多くの労力を費やしたという点で、興味深いものです。

上記はすべて、意欲的なカーネル開発者が参加できる場所のように思えます。

MAINTAINERSファイルに文書化されていないサブシステムについてはどうでしょうか?MAINTAINERS ファイルに含まれていないカーネルツリーのすべてのファイルをクイックスクリプトで調べると、得られます。この中には当然MAINTAINERSファイルそのものも含まれています。残りの大部分はinclude/の下にあるヘッダーファイルで、おそらくそのほとんどにメンテナがいて、MAINTAINERSファイルの適切なエントリに追加されるはずです。しかし、苛立たしいことに、kernel/ディレクトリには、メンテナがリストされていないファイルが72個もあります。これは確かにそうではありません。SYSV IPC」コードはメンテナンスされておらず、一般的な不人気を反映しています。残りのメンテナンスされていないファイルのほとんどは tools/ または samples/ ディレクトリにあります。

見つけるのが難しいのは、MAINTAINERSに含まれていると主張されているファイルの中には、それを指定した人が実際には保守していないものがあるということです。これはディレクトリツリー全体を含むように指定されたエントリの場合によくあります。例えば、エディタはDocumentation/ディレクトリで作業する必要があるとリストされていますが、確かに私が実際にそれだけのファイルを「保守」しているとは言えません。同じような状況は、カーネルツリーの多くの場所で見られます。

このデータから全体的な結論を導き出したいのであれば、次のようなことが言えるかもしれません: MAINTAINERSファイルには間違いなくいくつかの暗いコーナーがあり、それらのコーナー自体にはメンテナンスが必要かもしれません)。MAINTAINERSが不足しているカーネルのある部分はまだ使えますし、ある部分は古すぎてメンテナンスが必要です。しかし、ほとんどの場合、カーネルのサブシステムには指定されたメンテナがいて、そのほとんどは少なくとも担当するコードをメンテナンスしようとしています。もっと悪いこともあります。

.

Read next