6月21日
そのLinux 4.
このKDBUSのメインライン統合について、
Andy Lutomirskiという開発者のこの投稿には、
- APIが巨大。サンドボックス形式を採用していてメタデータの収集もスムースでパフォーマンスに影響が出ないという触れ込みだが、
メインラインにマージしたところで少ししか速くならないはず。メインラインではなくユーザ空間に実装すべき - KDBUSのバッファリングモデルは斬新すぎてトラブルのもとになる。senderが勝手にreceiverのtmpfsスペースに同期して書き込んでしまうことも十分に起こり得る
- サンドボックスモデルがそもそも成功するとは思えない
Lutomirskiがとくに強調しているのはパフォーマンスについてだ。彼は高速化を図りたいならKDBUSをメインラインではなくユーザ空間に実装すべきと何度も提案している。
これに対しLinus Torvaldsはどう反応したのだろうか。6/
僕は
(KDBUSを) マージできるといまも期待している。その理由はきわめてシンプルだ: 僕はサブメンテナーを信用している。とくにGKHをね。 (GKHのような) 重要なサブメンテナーが何かをマージしたいと言ってきたなら、 僕にとってもそれは重い意味をもつ。 それはさておき、
パフォーマンスの問題でKDBUSのマージについていまさら議論するのは、 僕にとって本当に失望することだと言っておく。これまで (KDBUSの元となる) D-Busのユーザ空間への実装を見てきて気づいたのは、 パフォーマンスがひどいのはユーザ空間のコードがクソなのが理由だということ。だから僕はパフォーマンスの問題についてはまったくもって関心がない。僕らは 「ユーザ空間が知恵遅れのサルにクラックされたから、 カーネル側でなんとかしてほしい」 という要請に応えてKDBUSをカーネルにマージするわけじゃない。カーネルのパフォーマンスを高いレベルで保つのはもちろん大事だ。だが、 「ユーザ空間のコードがクソだから」 というのはカーネルにマージする際の理由になったりはしない。 というわけで、
パフォーマンスの向上なんて論点で来るのは退屈でしょうがないんだよ、 僕にとって。
KDBUSの統合はここ1、