ファイルシステムにRustを使う
目標
- Rustの型システムを使って、より多くのエラーをコンパイル時に検出する
- リソース解放のような作業を自動化し、Cコードより生産性を高める
- メモリ関連の脆弱性を減らし、デバッグ時間を短縮する
Rustの利点
- Rustは未定義動作を排除し、コード内部で何が起きているのかを把握できる機能を提供する
- Rustで書かれたコードの正確性を証明できるため、機能開発を妨げるバグが減る
Rust型システムの例
iget_locked() 関数は複雑な要件を持っている- Rustでは
get_or_create_inode() 関数に置き換え可能で、型システムを通じてこうした要件を強制できる
API名変更に関する議論
- C APIとRust APIの名前の不一致という問題
- 既存の開発コミュニティにはなじみがない可能性がある
- 名前を一致させる必要があるかもしれない
一般的な問題
- Rust抽象化をすべてのカーネルファイルシステムで一般的に使うのか、それともRustで書かれたシンプルなファイルシステムにだけ注力するのかを決める必要がある
- Cコードが進化するにつれて、Rustコードとの同期問題が発生する可能性がある
オブジェクトのライフサイクル問題
- オブジェクトのライフサイクルはファイルシステムによって異なる場合がある
- Rust APIに単一のライフサイクルをエンコードすると、一部のファイルシステムでは動作しない可能性がある
Rustバインディングの問題
- すべてのファイルシステムが直ちにRustへ移行するわけではない
- Cコードが進化するにつれてRustバインディングが壊れる可能性がある
- Rustバインディングが壊れた場合、それはRust-for-Linux開発者たちの問題として残る
結論
- Rustバインディングの開発を続けつつ、Cコードも進化できるようにする
- Rust型システムに多くの意味をエンコードすることが良いのか悪いのかは、時間が経てば明らかになるだろう
GN⁺のまとめ
- Rustをファイルシステムに導入することは、メモリ安全性と生産性の向上に大きく役立つだろう
- Rust型システムによって複雑なAPI要件を強制でき、コードの正確性を高められる
- 既存のC開発者がRustを学ばなければ、同期問題のような困難が発生する可能性がある
- Rustバインディングが壊れた場合、それを解決するのはRust-for-Linux開発者たちの役割になるだろう
- 類似の機能を持つプロジェクトとしてはGoogleのFuchsia OSがある
1件のコメント
Hacker Newsのコメント
各ファイルシステムが inode のライフサイクルをそれぞれ異なる形で管理しているのに、同じ関数で扱おうとするのは抽象化レイヤーに反している
Rust が C 呼び出しをより容易にするために変更が必要なのか、という疑問がある
Rust API が C API をラップしているのか、それとも再実装しているのかが明確ではない
Rust をカーネルに追加することは、追加の複雑さを招く
議論は非常に礼節あるものだ
Linux カーネルに選択肢が増えることは、常に有益だ
lwn.net のページ下部にある一部のコメントは失礼だ
C API と Rust API の名前の不一致問題についての議論