4.1がリリースされた。Support)カーネルとして今後は多くのディストリビューションで使われることになる。4.1で実現しなかったエンハンスのひとつにKDBUSのメインカーネル統合がある。Kroah-Hartmanが熱心に開発を進めていることもあり、Linusも全幅の信頼を置いている発言をみせてきたが、残念ながら4.1でのマージは見送られた。次の4.2に向けてGKHがふたたびプルリクエストを出しており、Linusもこれを承認すると思われる。このKDBUSのメインライン統合について、カーネル開発メーリングリストであるlkml.orgにある疑問の声が投げかけられた。僕はないと思う」と、その理由について長いコメントが付されている。Lutomirskiという開発者のこの投稿には、KDBUSをマージする必要がない理由として大きく以下の3つが挙げられている。サンドボックス形式を採用していてメタデータの収集もスムースでパフォーマンスに影響が出ないという触れ込みだが、メインラインにマージしたところで少ししか速くならないはず。メインラインではなくユーザ空間に実装すべきKDBUSのバッファリングモデルは斬新すぎてトラブルのもとになる。senderが勝手にreceiverのtmpfsスペースに同期して書き込んでしまうことも十分に起こり得るサンドボックスモデルがそもそも成功するとは思えないLutomirskiがとくに強調しているのはパフォーマンスについてだ。彼は高速化を図りたいならKDBUSをメインラインではなくユーザ空間に実装すべきと何度も提案している。Torvaldsはどう反応したのだろうか。6/23付の投稿でLinusはこう答えている。merge?僕は(KDBUSを)マージできるといまも期待している。僕はサブメンテナーを信用している。(⁠GKHのような)重要なサブメンテナーが何かをマージしたいと言ってきたなら、僕にとってもそれは重い意味をもつ。それはさておき、パフォーマンスの問題でKDBUSのマージについていまさら議論するのは、僕にとって本当に失望することだと言っておく。これまで(KDBUSの元となる)D-Busのユーザ空間への実装を見てきて気づいたのは、パフォーマンスがひどいのはユーザ空間のコードがクソなのが理由だということ。僕はパフォーマンスの問題についてはまったくもって関心がない。僕らは「ユーザ空間が知恵遅れのサルにクラックされたから、カーネル側でなんとかしてほしい」という要請に応えてKDBUSをカーネルにマージするわけじゃない。カーネルのパフォーマンスを高いレベルで保つのはもちろん大事だ。「⁠ユーザ空間のコードがクソだから」というのはカーネルにマージする際の理由になったりはしない。いうわけで、パフォーマンスの向上なんて論点で来るのは退屈でしょうがないんだよ、僕にとって。KDBUSの統合はここ1、2年、systemdやPulseAudioとともにマージすべき機能のトップにランクインされてきた。ユーザ空間でD-Busを適用するよりもパフォーマンスやセキュリティの面ですぐれているからだが、設計思想やレビュアーの少なさからメインライン統合に反対する向きも少なくなかった機能でもある。くすぶるKDBUSマージへの反対の声だが、次の4.2で無事に取り込まれるかどうかに注目したい。Ltd.ページ内容の全部あるいは一部を無断で利用することを禁止します⁠。個別にライセンスが設定されている記事等はそのライセンスに従います。