6月21日（米国時間⁠）⁠、8回のリリース候補版（rc）を経て無事にLinux 4.1がリリースされた。ext4の暗号化機能やMD RAIDによるRAID 5/6サポート、XenゲストユーザのためのvGPUサポートなどさまざまな機能強化が実施されており、さらに2年保証のLTS（Long Time Support）カーネルとして今後は多くのディストリビューションで使われることになる。

• LKML: Linus Torvalds: Linux 4.1 released

そのLinux 4.1で実現しなかったエンハンスのひとつにKDBUSのメインカーネル統合がある。KDBUSの統合に関しては、カーネルメンテナーの中心的人物のひとり、GKHことGreg Kroah-Hartmanが熱心に開発を進めていることもあり、Linusも全幅の信頼を置いている発言をみせてきたが、残念ながら4.1でのマージは見送られた。だが次の4.2に向けてGKHがふたたびプルリクエストを出しており、Linusもこれを承認すると思われる。

このKDBUSのメインライン統合について、カーネル開発メーリングリストであるlkml.orgにある疑問の声が投げかけられた。「⁠KDBUSは本当にメインラインにマージする必要があるのか？ 僕はないと思う」と、その理由について長いコメントが付されている。

• LKML: Andy Lutomirski: kdbus: to merge or not to merge?

Andy Lutomirskiという開発者のこの投稿には、KDBUSをマージする必要がない理由として大きく以下の3つが挙げられている。

1. APIが巨大。サンドボックス形式を採用していてメタデータの収集もスムースでパフォーマンスに影響が出ないという触れ込みだが、メインラインにマージしたところで少ししか速くならないはず。メインラインではなくユーザ空間に実装すべき
2. KDBUSのバッファリングモデルは斬新すぎてトラブルのもとになる。senderが勝手にreceiverのtmpfsスペースに同期して書き込んでしまうことも十分に起こり得る
3. サンドボックスモデルがそもそも成功するとは思えない

Lutomirskiがとくに強調しているのはパフォーマンスについてだ。彼は高速化を図りたいならKDBUSをメインラインではなくユーザ空間に実装すべきと何度も提案している。

これに対しLinus Torvaldsはどう反応したのだろうか。6/23付の投稿でLinusはこう答えている。

• LKML: Linus Torvalds: Re: kdbus: to merge or not to merge?

僕は（KDBUSを）マージできるといまも期待している。その理由はきわめてシンプルだ: 僕はサブメンテナーを信用している。とくにGKHをね。（⁠GKHのような）重要なサブメンテナーが何かをマージしたいと言ってきたなら、僕にとってもそれは重い意味をもつ。

それはさておき、パフォーマンスの問題でKDBUSのマージについていまさら議論するのは、僕にとって本当に失望することだと言っておく。これまで（KDBUSの元となる）D-Busのユーザ空間への実装を見てきて気づいたのは、パフォーマンスがひどいのはユーザ空間のコードがクソなのが理由だということ。だから僕はパフォーマンスの問題についてはまったくもって関心がない。僕らは「ユーザ空間が知恵遅れのサルにクラックされたから、カーネル側でなんとかしてほしい」という要請に応えてKDBUSをカーネルにマージするわけじゃない。カーネルのパフォーマンスを高いレベルで保つのはもちろん大事だ。だが、「⁠ユーザ空間のコードがクソだから」というのはカーネルにマージする際の理由になったりはしない。

というわけで、パフォーマンスの向上なんて論点で来るのは退屈でしょうがないんだよ、僕にとって。

KDBUSの統合はここ1、2年、systemdやPulseAudioとともにマージすべき機能のトップにランクインされてきた。ユーザ空間でD-Busを適用するよりもパフォーマンスやセキュリティの面ですぐれているからだが、設計思想やレビュアーの少なさからメインライン統合に反対する向きも少なくなかった機能でもある。いまだにくすぶるKDBUSマージへの反対の声だが、次の4.2で無事に取り込まれるかどうかに注目したい。