Greg K-H: 「Rustで新しいコードを書くことはみんなに利益がある」
(lore.kernel.org)LinuxカーネルにRustを導入すべき理由
- 過去15年間にわたり、ほぼすべてのLinuxカーネルのバグ修正とセキュリティ問題を見てきた経験をもとに、Rust導入の必要性を語りたい
- すべてのバグ修正が安定版ツリーに反映されるわけではないが、おおむね重要なものは反映されており、私はすべてのカーネルCVEを確認する立場にある
Cの限界とRustの利点
- Linuxカーネルで発生するバグの大半は、C言語の構造的な限界に起因している
- 特に、単純なミスによって発生するバグが多く、このような問題はRustではほとんど発生しない
- メモリ上書き（Rustがすべてのケースを検出できるわけではないが、かなりの部分を解決できる）
- エラーパスのクリーンアップ問題
- エラー値のチェック漏れ
- Use-after-free（解放後使用）バグ
- Rustをカーネルに導入すれば、開発者やメンテナーはこうした初歩的なミスから解放され、本当に難しい問題（ロジックエラー、競合状態など）に集中できる
既存のCコードベースも引き続き維持する必要がある
- 現在のLinuxカーネルは3,000万行を超えるCコードで構成されており、短期間でこれをRustに置き換えることは不可能である
- したがって、KeesやGustavoをはじめとする開発者たちが進めているCコードのセキュリティ強化作業は不可欠であり、継続されるべきである
- Rustが既存コードを置き換えるのではなく、新しいコード（特にドライバ）をRustで書いて問題を減らす方式が理想的である
Rustが提供するAPIの安全性
- Rustはカーネル内部APIをより安全で使いやすく設計できるようにする
- 現在のCベースのカーネルAPIは複雑でミスを誘発しやすく、メンテナーが細かくレビューしなければならないことが多い
- たとえば、
struct cdevのような構造体を安全に使う方法はいくつもあり、それを正しく活用するには多くの経験が必要である - Rustを使えばAPIをより明確に定義できるため、開発者がミスをする可能性を大きく減らせる
- これは単にRust利用者のためだけではなく、既存のCコード利用者にとっても有益な変化である
Rust導入は難しいのではないかという懸念への反論
- Rustは万能の解決策ではない → しかし既存の問題のかなりの部分を解決できる
- メンテナーの負担増 → しかしRust導入を望む開発者たちが自ら作業を進めている
- 混在言語コードベースの保守の難しさ → しかしLinuxカーネルはこれまで、はるかに難しい問題を解決してきた
結論
- Linuxは世界中の無数の開発者が問題解決のために使うツールであり、
- 今やハードウェア向けに安全なコードを書きたいという開発者の要求があるなら、それを無視すべきではない
- Linuxの開発モデルは誰も予想しなかった規模にまで成長し、卓越したエンジニアリング能力を示してきた
- いまこそRust導入を通じて、今後20年以上の発展に向けて進むべき時である
新しい技術とアイデアを受け入れ、コミュニティとともに成功できるよう努力しなければならない。
24件のコメント
Rust の導入は、memory safety を考えると避けがたい変化でしょう。おそらく適度な折衷案を通じて、再び取りまとめを試みるのではないかと思います。
ただ、個人的には Rust のキーワードがあまり目に入ってこなかったり、しばらくしてから見返したときにまた思い出しにくかったりして、どうも手が伸びないんですよね ;;;; どれも必要なものだとは分かっていますが、英語の不規則動詞を無理やり暗記するような感覚になることがあります。それでも、Rust で書かれた成果物が現場で問題を起こしにくいのもまた事実なので.....
まだ成熟していない言語をカーネルに含めないということが、ここまで非難されるようなことなのかと思います。今すぐ身の回りで Rust を手慣れたレベルで扱える人を探してみろと言われても、ほとんどいないのではないでしょうか。言語がもう少し成熟し、ユーザーもレガシー言語のユーザーほどではないにせよ十分に確保できた時に含まれても遅くはないと思います。
Rust 言語が有用だということは、Linux カーネルに適用されなくても十分に証明できると信じています。
Rustが今くらいの段階でも「まだ成熟していない言語」と言われること自体も驚きですが、それとは別に、いまだに安全でない言語の比重をカーネルで減らしていこうというのが、ここまで非難されることなのかと思います。実際、周りにC言語でカーネルに貢献できるほど習熟したうえで安全なコードを書ける人が、そんなに多いでしょうか。C言語にこれ以上の成熟を期待するよりも、新しい時代の要求が十分に整った今こそ、遅すぎない時期なのだと思います。
Rustはすでに有用であり、カーネルに取り込まれようとしているのは、その有用性を証明するためではないのでしょう。
最初にRustを導入しようとしたとき、議論はあったのだろうとは思う。
Cの熟練者とRustの熟練者のどちらが層として厚いかを考えると、Cのほうが圧倒的ではあるだろう。
とはいえ、すでにドメイン知識を十分に持っているプログラマが言語を1つ追加で学ぶことが、そこまで大変なことなのかとも思うが、
カーネルを扱う人たちが求める習熟度となると、また別の話なのだろうけど……
この意見もいいですね
「フォークして出ていけ」という主張は、まったく理解できません。いったいなぜリーナスがLinuxをフォークして出ていかなければならないのでしょうか？
リーナスに「フォークして出ていけ」と言う人がいるんですか？ この論争でそんなことを言う人は見たことがない気がするのですが..
私もRustユーザーですが、RustコードとCコードが混在すると、オープンソースでどこまでRustコードを許容するのかという厳格な規約がない限り、制御不能になるか、少なくともレビューや保守のコストが非常に上がるように思います。なので、追加せずにforkするのが最も賢明な選択だと見ています。
カーネルはあまり詳しくありませんが、CコードをRustに自動翻訳できるならいいなと思います。もちろん、コード翻訳の問題だけでなく人の問題もあるでしょうが。
カーネルにRustを導入してほしい人がこれほど多いのなら、フォークして新しいプロジェクトに移ればいいのではありませんか？ そうして十分に成熟したら、主要なディストリビューションがRustベースのカーネルへ移行することになるでしょう。
なぜお互いに争っているのか、よく分かりません。
カーネル開発の経験がある方なのか私にはよく分からないので、何と申し上げればよいのか分かりませんが、
まず、Rust言語を適用するというのは、カーネルをRustに置き換えようという話ではありません。分離して別のカーネルを作ればいいのではないかと思われるかもしれませんが、
Rust言語でカーネルを作ろうというのではなく、カーネル内でデバイスドライバ向けのインターフェースだけをRustでwrapperとして作り、デバイスドライバだけをRustで
作れるように改善してみよう、ということです。ですので、新しいプロジェクトにするというのは意味がありません。
Linux側の開発をしたことはありません。
デバイスドライバのRustラッパーは、カーネルから切り離せない構造なのですね...
カーネルの安定性を理由に攻撃的な物言いを正当化してきたLinuxコミュニティが、今になって「気に入らないならフォークしろ」という反応を理にかなった返答だと見なしているのは、なんとも皮肉ですね。
私はLinuxコミュニティの人間ではありませんが...
その方々とこのコメントの投稿者を同じコミュニティと見なすべきではないと思います。
フォークした結果がマイグレーションになるのか、群雄割拠の時代になるのか予想しにくいところがありそうです。
フォークした後もアップストリームの変更事項を反映するのは、あまり気分のよい状況ではなさそうです。
https://ja.news.hada.io/topic?id=16860
Realtime Linuxのフォークが20年ぶりに統合されたことを見ても、フォークは慎重に判断すべきではないかと思います
私はこれを見てそう話していたんです。
リアルタイム機能を長い間カーネルから分離したプロジェクトとして維持できていて、必要な人はそれを取り込んでカーネルに適用して使えばよかったんですから。
Rustユーザーではありますが、r/rust に投稿された hgwxx7_ のコメントが印象的でした1。
stableバージョンへのバックポートが必要になるなどして連絡してみると、あれほど忙しい中でもきちんと返事をくれたのを覚えています。
"Rustで新しいコードを書くことは、みんなにとって利益になる" - Greg K-H
"Rustが唯一の正解ではないが、JavaやPythonよりは正解に近い" -codemaster kimc-
Hacker Newsの意見
こういうヘイトコメントは通報できないのですか？
同意します。