C言語守護者 vs Rust推進派：Linuxカーネルで起きた2025年の路線対立（Rust for Linux）
はじめに
Rust for Linux プロジェクトとは
Rust for Linuxは、メモリ安全性に優れたプログラミング言語Rustを、Linuxカーネル内で使用できるようにする取り組みです。このプロジェクトは2020年頃から非公式な議論が始まり、2021年4月にMiguel Ojeda氏によって正式にLinuxカーネルメーリングリスト（LKML）に提案されました。
プロジェクトの主な目的は、メモリ関連のバグやセキュリティ脆弱性を減らすことです。Rustは「安全性」を設計原則とする言語であり、コンパイル時に多くのエラーを検出できるため、従来のC言語で発生しがちなバッファオーバーフローやダングリングポインタなどの問題を防ぐことができます。
重要なのは、Rust for Linuxの目標はカーネルの中核部分を書き換えることではなく、主にデバイスドライバなどの「葉」モジュールをRustで書けるようにすることです。
Please note that the Rust support is intended to enable writing drivers and similar "leaf" modules in Rust, at least for the foreseeable future. In particular, we do not intend to rewrite the kernel core nor the major kernel subsystems (e.g.
kernel/,mm/,sched/...). Instead, the Rust support is built on top of those.https://lore.kernel.org/lkml/20210414184604.23473-1-ojeda@kernel.org/
Linus Torvalds氏も原則としてこのアプローチに賛成しており、2022年頃から徐々にRustコードがLinuxカーネルに取り込まれるようになりました。しかし、長年C言語で開発されてきたLinuxカーネルに新しい言語を導入することは、技術的な課題だけでなく、コミュニティ内の文化や権力構造にも大きな影響を与えています。
2025年初め、Rust for Linux プロジェクトが再びオープンソースコミュニティの焦点となりました。この波乱に満ちたプロジェクトは新年早々、メンテナーの辞任、ネット上での論争、さらには Linus Torvalds 自身の介入を引き起こす激しい対立を生み出しました。2024年の衝突がまだ技術理念のレベルにとどまっていたとすれば、2025年の争いはすでに権力闘争へと発展したと言えるでしょう。
今回の衝突の焦点はコンピュータシステムにおける重要な機能：DMA（Direct Memory Access、直接メモリアクセス）でした。なぜこの争いがこれほど大きくなったのかを理解するために、まず DMA がシステム内で果たす役割について把握する必要があります。
重要な DMA の役割
コンピュータシステムでは、CPUが中核的な制御者として各コンポーネントの作業を調整しています。マザーボードを注意深く観察すると、CPUの周りに多くの配線があることに気づくでしょう。これらはCPUが管理するチャネルであり、システムバス（System Bus）と呼ばれています。
システムバスは次の三つの部分から構成されています：
- 制御バス（Control Bus）：CPUと他のコンポーネント間で命令を伝達するため
- アドレスバス（Address Bus）：CPUがメモリにアドレスを送信するため
- データバス（Data Bus）：コンポーネント間でデータを転送するため
例えば、プログラムがメモリからデータを読み取る必要がある場合、CPUはアドレスバスを通じてアドレスを送信し、制御バスを通じて読み取り命令を出し、最後にメモリはデータバスを通じて対応するデータを返します。
この設計は初期のコンピュータでは非常に合理的でした。CPUがパフォーマンスが最も高いコンポーネントだったからです。しかし、ハードディスク、ネットワークカード、グラフィックカード、サウンドカードなど様々なデバイスが爆発的に増加するにつれ、これらのデバイスは大量のデータ転送を必要とするようになりました。もしすべてのデータ転送タスクがCPUによって割り当てられるなら、CPUは計算タスクに集中できなくなります。
そこでハードウェア開発者はDMA（Direct Memory Access）技術を発明しました。DMAはデバイスがCPUにシステムバスの一時的な管理を申請できるインターフェースを提供します。例えば、ネットワークカードが大量のデータをダウンロードする際、ネットワークカードドライバはDMAを通じてCPUにシステムバスの管理を申請し、直接メモリに書き込み要求を送信して書き込みアドレスを指定し、データを直接メモリに書き込みます。このプロセス全体でCPUの関与は不要となり、効率が大幅に向上します。
DMAには3つの管理モードがあります：
- バーストモード（Burst Mode）：データのブロック全体を連続して転送し、CPUは比較的長い時間非アクティブになります。このモードは、ハードディスクからメモリへのデータ読み込みなどに適しています
- サイクルスティーリングモード（Cycle Stealing Mode）：CPUとシステムバスを交代で使用し、DMAコントローラーがデータを1ユニットずつ転送します。これにより、CPUは命令を処理しながらデータ転送が行われ、リアルタイムでのデータ監視に適しています
- トランスペアレントモード（Transparent Mode）：CPUがシステムバスを使用していないときのみデータを転送します。このモードは、優先度の低いバックグラウンドプログラムに適しており、CPUは常にプログラムを実行し続けることができます
Linuxシステムでは、DMAは特に重要です。Linuxカーネルの重要な使命の一つが様々なハードウェアとの互換性を確保することであるため、カーネルコードの60%以上が各種ハードウェアドライバとなっており、これらのドライバの大部分がDMAインターフェースを呼び出す必要があります。そのため、Rust for Linuxプロジェクトにおいて、DMAとの互換性は重要な前提条件となっています。
紛争の導火線
2025年1月8日、Rust開発者のAbdiel Janulgueが既存のC言語版DMAインターフェースのマッピングをRustで実装したプルリクエスト（PR）を提出し、Rust版DMAインターフェースの基盤を築きました。
[PATCH v8 2/2] rust: add dma coherent allocator abstraction.
Add a simple dma coherent allocator rust abstraction. Based on Andreas Hindborg's dma abstractions from the rnvme driver, which was also based on earlier work by Wedson Almeida Filho.https://lore.kernel.org/lkml/20250108122825.136021-3-abdiel.janulgue@gmail.com/
しかし、このPRはChristoph Hellwigによって拒否されました。DMA Mapping Helpersのメンテナーの一人として、Hellwigの理由は簡潔明瞭でした：
No rust code in kernel/dma, please.
その後の議論で、Hellwigは技術的な議論を一切行う意思がないことを明確にし、彼の目標はRustコードがLinuxカーネルに入ることを可能な限り阻止することだと述べました：
Which doesn't help me a bit. Every additional bit that the another language creeps in drastically reduces the maintainability of the kernel as an integrated project. The only reason Linux managed to survive so long is by not having internal boundaries, and adding another language complely breaks this. You might not like my answer, but I will do everything I can do to stop this. This is NOT because I hate Rust. While not my favourite language it's definitively one of the best new ones and I encourage people to use it for new projects where it fits. I do not want it anywhere near a huge C code base that I need to maintain.
https://lore.kernel.org/rust-for-linux/20250131075751.GA16720@lst.de/
この強硬な姿勢は一つの疑問を投げかけました：なぜHellwigはこのPRを一方的に否決する権限を持っているのでしょうか？これを理解するためには、Linuxカーネルの権力構造を把握する必要があります。
Linux カーネルの権力構造
Linuxは「優しい終身の独裁者」（BDFL、Benevolent Dictator For Life）体制のオープンソースプロジェクトであり、創始者のLinus Torvaldsが最終決定権を持ち、彼のブランチのみが正統なLinuxカーネルとみなされています。
優しい終身の独裁者（やさしいしゅうしんのどくさいしゃ、Benevolent Dictator For Life、省略形BDFL、より直訳的には「慈悲深き終身の独裁官」）とは、オープンソースソフトウェア開発プロジェクトの少数のリーダーに与えられる称号である。一般的には、コミュニティ内で論議、論争が発生した際に最終的な仲裁を行う権利を持つプロジェクト創設者であることが多い。
しかし、Linuxカーネルの規模が膨大なため、Linusが全てのコードを自ら審査することは不可能です。そこで、彼は審査権を世界中のメンテナー（Maintainer）に分配しました。現在、Linuxカーネルは2967のコンポーネントに分けられ、1800人ぐらいのメンテナーが担当しています。これらのメンテナーの名前とメールアドレスはカーネルのソースコードに記録されています。
Linuxカーネルメンテナーリストはこちらで確認できます：
https://github.com/torvalds/linux/blob/master/MAINTAINERS
Linuxカーネルにコードを提出するには、まずコードがどのコンポーネントに属するかを確認し、対応するメンテナーにPRを送信する必要があります。メンテナーがPRを受け入れると、自分のブランチに統合してLinusに提出します。
Lf Asia, CC BY 3.0 https://creativecommons.org/licenses/by/3.0, via Wikimedia Commons
2003年から、Linuxカーネルは平均10週間ごとにリリースされ、毎回数万のPRと数百万行のコードが統合されています。Linusは各PRを個別に審査することは不可能であり、具体的に何が統合されたかを知らない場合もあります。彼は長年かけて検証されたこれらのメンテナーを信頼しており、それがプロジェクト全体の運営を維持する唯一の方法だからです。
DMAのコンポーネント分割では、DMA機能は5つのコンポーネントに分けられ、HellwigはDMA Mapping Helpersの2人のメンテナーの1人でした：
DMA MAPPING HELPERS
M: Christoph Hellwig hch@lst.de
...
https://github.com/torvalds/linux/blob/v6.13/MAINTAINERS#L6807-L6808
したがって、現在の権力構造下では、Hellwigは確かにこのPRの統合を阻止する権限を持っていました。
権力の駆け引き
HellwigがJanulgueのPRを拒否した後、数人のメンテナーがメーリングリストでHellwigと議論しましたが、彼は実質的な議論を一切拒否しました。
2025年2月3日、Hector Martinというメンテナーがこの衝突を公にすることを決めました。MartinはAIM Apple Machine Supportコンポーネントを担当しており、主にアップルのM1チップとの互換性を確保する役割を担っていました。DMA問題と直接の関係はありませんでしたが、彼はソーシャルメディアでHellwigの権力乱用行為を公に批判し、Linusの介入を求めました：
As for how to move forward, if I were one of the Rust maintainers, I would just merge the patch (which does not touch code formally maintained by the dissenter). Either Linus takes the pull, and whatever Christoph says is irrelevant, or he doesn't, and R4L dies. Everything else is a waste of everyone's time and energy.
Martinは、Hellwigをバイパスして直接PRをLinusに提出し、彼が受け入れるかどうかを見ることを提案しました。Linusが受け入れれば、彼がHellwigのやり方を支持していないことを意味し、受け入れなければRust for Linuxプロジェクトの終わりを意味します。
この公開声明は、内部の技術的議論から公衆の目に衝突を押し出しました。2025年2月6日、Linusはついに応答しましたが、予想外にも、彼はDMAやHellwigの問題に直接言及するのではなく、Martinのやり方を厳しく批判しました：
How about you accept the fact that maybe the problem is you.
You think you know better. But the current process works.
It has problems, but problems are a fact of life. There is no perfect.However, I will say that the social media brigading just makes me not want to have anything at all to do with your approach.
Because if we have issues in the kernel development model, then social media sure as hell isn't the solution. The same way it sure as hell wasn't the solution to politics.
Technical patches and discussions matter. Social media brigading - no thank you.
Linusは、コミュニティ内の対立はコミュニティ内で解決すべきであり、論争を公にして外部の力を動員して他の開発者を攻撃することはコミュニティが容認できない行為だと述べました。
失望したMartinは翌日メンテナーの職を辞し、自らが立ち上げたアップルチップ互換プロジェクトから撤退しました：
I no longer have any faith left in the kernel development process or community management approach.
https://lore.kernel.org/lkml/CAEg-Je_SSTiiq5R9hce-7j5W02GaQqNUj=bFH+FwgjjxWugFqQ@mail.gmail.com/T/
Rustを支持する側の士気は挫かれ、その後の議論では次第に劣勢に立たされました。
最終的な仲裁
2025年2月20日、2週間沈黙を守っていたLinusが再び発言しました。彼は以前の沈黙はコミュニティが内部議論で問題を解決できるかを観察するためだったと説明しましたが、明らかに議論は行き詰まっていたため、彼は仲裁を行うことを決定しました。
Linusは、問題の核心はRust for Linuxプロジェクトの位置づけではなく、メンテナーの役割の定義にあると指摘しました。メンテナーとしての責務はコンポーネントのコードを維持することであり、他者がそのコンポーネントをどのように使用するかを決定する権限はないのです：
It was literally just another user of it, in a completely separate subdirectory, that didn't change the code you maintain in any way, shape, or form.
Honestly, what you have been doing is basically saying "as a DMA maintainer I control what the DMA code is used for".
So this email is not about some "Rust policy". This email is about a much bigger issue: as a maintainer you are in charge of your code, sure - but you are not in charge of who uses the end result and how.
Linusは、Janulgueが提出したRust DMAインターフェースマッピングは本質的にはDMAコンポーネントのユーザーにすぎず、Rustフォルダに書かれてRustコードが使用するためのもので、既存のDMAコンポーネントに対する変更は一切ないことを強調しました。したがって、DMAメンテナーであっても、この種の使用方法を拒否する権限はありません。
Linusはさらに、HellwigおよびRustに敵意を持つ他の古参メンテナーに明確な選択肢を示しました：
You are not forced to take any Rust code, or care about any Rust code in the DMA code. You can ignore it.
But "ignore the Rust side" automatically also means that you don't have any say on the Rust side.
この発言は近年のRustとLinuxの衝突に決着をつけました：メンテナーはRust開発に参加しないことを選択できるが、その場合はRustコードに干渉する権限もない。Rust開発に参加する場合は、Rustコードに提案を行うことができます。
Hellwigは譲歩を選びました。Linusの発言から4日後、彼は静かにPRを提出し、自身をDMA Mapping Helpersのメンテナーリストから削除しました：
https://lore.kernel.org/lkml/20250224162724.349679-1-hch@lst.de/
Linusはその日のうちにこの変更を受け入れました。注目すべきは、HellwigがLinuxカーネル開発から完全に撤退したわけではなく、他の4つのコンポーネントのメンテナーとしての地位を保持していることです。
波乱を経験したRust DMAインターフェースは発展を続け、2025年3月11日の時点で第14版にまで更新されています。
https://lore.kernel.org/lkml/4a0350b7-9b82-48e1-9d8a-04a8fed072c7@samsung.com/
このPRは新たなコンポーネント「DMA Mapping Helpers Device Driver API Rust」を形成し、JanulgueともうひとりのRust支持者がメンテナーを共同で務めています。
考察と示唆
このLinuxコミュニティの衝突を振り返ると、DMA機能自体と似たような特徴があることに気づきます：どちらも強力な中核を維持しながら、中核の負荷を超える多様なシナリオに対応する必要があります。どちらも権力と責任を分散させながら、権力の制御不能なリスクに対処しなければなりません。最終的には、健全な協力メカニズムを確立して衝突を解消する必要があります。
オープンソースコミュニティでは、技術的理念の衝突は避けられませんが、合理的な権力構造と明確なルールを通じて、これらの衝突が最終的にプロジェクトを前進させる原動力へと変わることができるのです。
結びに：今後の展望と技術的な意義
今回ご紹介した衝突は、Rust for Linuxプロジェクトにおける氷山の一角に過ぎません。このプロジェクトが2020年に始まって以来、C言語を守る保守派とRustを推進する革新派の間には数多くの対立が存在してきました。本稿では2025年初頭から現在までの論争に焦点を当てましたが、これはLinusがRust for Linuxプロジェクトを直接支持するために初めて公式に介入した重要な転換点でもありました。
Rust for Linuxプロジェクトの対立は、私たち技術者にとっては一種の「テクニカルドラマ」とも言えるでしょう。しかし、これらの対立を追うことで、単なる技術的議論を超えて、世界最高レベルのオープンソースプロジェクトの内部力学や意思決定プロセスを理解するための貴重な洞察が得られます。さらに、DMAの仕組みやカーネル開発の組織構造など、多くの専門知識も得ることができます。
最後に、この記事の作成にあたり OpenAI に感謝の意を表したいと思います。私は日本語のネイティブスピーカーではありませんが、OpenAI のサポートにより、最初は英語と中国語で書いた内容を整理し、洗練させ、日本語に翻訳することができました。人工知能と人間のコラボレーションが、このような形で言語の壁を越え、複雑な技術的議論を共有することを可能にしている時代に生きていることは、非常に刺激的です。
オープンソース開発における対立は避けられませんが、それらの衝突を通じて私たちは成長し、より強固なソフトウェアエコシステムを構築していくのです。Rustの安全性とLinuxの堅牢性が共存する未来に、大いに期待したいと思います。
参考
- https://www.youtube.com/watch?v=ntmGx_FTzN8&ab_channel=SavvyNik
- https://openai.com/
- https://lore.kernel.org/lkml/
- https://commons.wikimedia.org/wiki/File:Lc3_2018_(263682303)_(cropped).jpeg
- https://gihyo.jp/article/2025/02/daily-linux-250228
- https://www.heise.de/en/news/Is-a-kernel-developer-blocking-the-success-of-Rust-for-Linux-Yes-and-no-10269318.html
- https://www.theregister.com/2025/02/05/mixing_rust_and_c_linux/
- https://www.youtube.com/watch?v=WiPp9YEBV0Q
- https://xenospectrum.com/conflict-over-the-introduction-of-rust-intensifies/
Discussion