BUS1がRustで復活──LinuxカーネルIPC再挑戦
あの「カーネル内IPC」が帰ってきた。10年前に道半ばで消えたプロジェクトが、言語ごと生まれ変わって再びメインライン統合を目指している。
あの「カーネル内IPC」が帰ってきた。10年前に道半ばで消えたプロジェクトが、言語ごと生まれ変わって再びメインライン統合を目指している。
KDBUSの亡霊が、Rustの衣をまとって立ち上がる
Linuxカーネル向けのケーパビリティベースIPC（プロセス間通信）であるBUS1が、Rust言語で全面的に書き直された新バージョンとして開発が進んでいる。2026年4月1日、オリジナル開発者のひとりであるダヴィッド・ラインスベルクが、Rust-For-Linuxメーリングリストに16パッチ・約9,000行のRFCを投稿した。
この動きが「驚き」と受け止められたのには理由がある。BUS1の前身であるKDBUSは、2014年にD-Busをカーネル空間に移植する試みとして提案されたが、設計上の論争と激しい政治的抵抗に遭い、Linux 4.1へのマージに失敗。その後BUS1として「白紙からの再設計」を掲げたものの、こちらもメインラインに到達することなく、事実上の活動停止状態にあった。
BUS1はKDBUSの失敗から生まれた、ケーパビリティベースのカーネル内IPCである。従来のD-Busがユーザー空間で動作するのに対し、BUS1はカーネル内で直接メッセージパッシングを行い、性能とセキュリティの両面で優位性を狙う。
開発者たちは方針を転換し、ユーザー空間で動作する高性能D-Bus実装「dbus-broker」の開発に注力してきた。dbus-brokerは現在FedoraやRHEL系ディストリビューションの標準D-Bus実装として採用されており、「カーネルに入れなくても実用的な解決策は作れる」ことを証明した存在だ。
それなのに、なぜ今さらカーネル内IPCに戻るのか。
「Rustで書き直すことが喜びだった」
ラインスベルクのメーリングリスト投稿には、技術者としての率直な感情がにじんでいた。10年前のアイデアは変わっていない。変わったのは実装言語だ。
CからRustへの移行で最も大きかったのは、参照カウントの所有権管理とオブジェクトのライフタイムをRustの型システムに任せられるようになったことだという。カーネルモジュール開発において、これらはバグの温床であり、C言語では開発者の注意力だけが防波堤だった。
ただし、トレードオフもある。C言語で書かれたLinuxカーネル本体との境界に「C⇔Rustブリッジ」が必要になり、現時点ではCに露出するすべての部分を手動でブリッジしている。便利なヘルパーやファストパス、複雑なAPI拡張は意図的に削ぎ落とされた。
今回のBUS1は「最小限のコア」に徹している。従来版にあった利便性機能を一切排除し、基本的なピア管理・ハンドル転送・メッセージパッシングだけを実装。足りない機能は将来のイテレーションで追加する方針だ。
この「引き算の設計」は、KDBUSが抱えていた問題への明確な回答でもある。KDBUSはD-Busプロトコルをそのままカーネルに持ち込もうとして批判を浴びた。BUS1はプロトコル非依存の汎用IPCとして設計されており、D-Busに限らずあらゆるメッセージバスの基盤になり得る。
「実験」ではなくなったRust、だからこそ意味がある
このタイミングでRust実装が登場したことには、もうひとつの文脈がある。2025年12月のLinux Kernel Maintainers Summitで、カーネル内のRustは「実験的」ステータスから正式なコアコンポーネントへと格上げされた。グレッグ・クロア＝ハートマンは「RustドライバはCで書かれたものより安全であることが証明されつつある」と発言している。
BUS1のRust実装は、この流れの延長線上にある。単なる「Rustで書いてみた」ではなく、カーネルのIPC基盤というミッションクリティカルな領域でRustの安全性を活用しようとする挑戦だ。
2026年初頭の時点で、Linuxカーネル内のRustコードは60万行を超えている。NVIDIAのオープンソースファームウェア向けNovaドライバ、AndroidのBinder書き直しなど、「本番環境で使われるRustカーネルコード」はもはや珍しくない。BUS1がこのエコシステムに加わることで、IPCという根幹的なサブシステムにもRustの波が到達することになる。
10年越しの帰還がメインラインに届くか
現時点でBUS1のRust版はRFC（Request for Comments）段階であり、メインラインへのマージはまだ先の話だ。ラインスベルクはまずRust-For-Linuxコミュニティからのフィードバックを求めており、カーネル本体のUAPI（ユーザー空間API）やバス管理部分のレビューは次のフェーズで行う予定だとしている。
過去を振り返れば、楽観はできない。KDBUSは複数回のリジェクトを経て消滅し、初代BUS1もメインラインに到達できなかった。Linuxのカーネル開発者コミュニティは「もうひとつの中途半端なIPCスタック」を抱えることに極めて慎重だ。
しかし、10年前とは状況が異なる。Rustがカーネルの正式言語になったこと。dbus-brokerで実績を積んだ開発者が設計していること。そして何より、「最小限のコア」から始めるという謙虚なアプローチ。KDBUSが「大きすぎて入らなかった」のだとすれば、新生BUS1は「小さく始めて、育てていく」戦略を取っている。
ラインスベルクはかつてダヴィッド・ヘルマンの名でRed Hatに在籍し、systemd、Wayland、BlueZなどLinuxの中核プロジェクトに関わってきた。BUS1とdbus-brokerの設計者でもあり、この領域における経験と信頼は厚い。
10年間の迂回路は、無駄ではなかったのかもしれない。dbus-brokerで学んだ「ユーザー空間で何ができて、何ができないか」の知見が、新しいBUS1の設計に反映されているはずだ。
カーネルのIPCは、30年以上にわたって「解決済みの問題」と「未解決の問題」の間を行き来してきた。パイプ、ソケット、共有メモリ、Binder——部分的な解決策は山ほどある。だが、汎用的で安全で高性能なカーネル内メッセージバスは、いまだに存在しない。BUS1がその答えになるかどうか、判断するには早すぎる。ただ、10年かけて同じ問いに向き合い続けている開発者がいるという事実は、それだけで注目に値する。
参照元
