鶏小屋を落ち着かせる: Linus Torvalds が Rust に対する自身の立場を強調

リニアトーバルズ

2月中ずっと私たちは さまざまなニュースを共有する 上の 問題や意見の相違がある場合 Linuxカーネル開発者コミュニティで生成されたもの Rust での開発用。

でも、 コミュニティの有力者の中には、自らの立場を明らかにした者もいる。 さらに悪いことに、 辞職した者もいる いくつかの Linux カーネル サブシステム内のメンテナーとして。

制御不能になりつつある議論の波を考えると、 Linus Torvalds 氏は自らこの問題に取り組みました。 y についての議論に参加しました Linux カーネルへの Rust の導入に対して一部のメンテナーが抵抗していること。

Linusによれば、メンテナーは学習したり使用したりすることを強制されない。 あるいは、 錆びたくないなら錆びろ C のみで作業を継続できるためです。

19年2025月22日水曜日午後42時XNUMX分、クリストフ・ヘルヴィグ書いた:
>
ドキュメントには、Rust を使用するのにサブシステムは必要ない、と記載されています。それは証明されています。
> Linus にとっては間違っている。そして、あなたがそれを知らなかったとしても
> 文書を書いたとき、あなたは間違いなくそれをリストに投稿しました。

私は期待して、この長いスレッドが結果をもたらすかどうか試してみました。
建設的な何かに変えようとしているが、これは後退しているようだ(少なくとも
少なくとも前進はしない。

事実は、あなたが反対したプルリクエストはDMAに触れなかったということです
レイヤーは一切ありません。

彼は文字通り、まったく別の状況にいる、ただのもう一人のユーザーでした。
サブディレクトリは、あなたが管理しているコードに何ら変更を加えていない。
形または形態。

しかしながらメンテナーが関与しないことを決定した場合、影響を与える機会もなくなる。 開発方法にも影響を与えず、外部リンクが独自のサブシステムのコードに統合される方法にも影響を与えません。

トルバルズ氏は次のように説明した。 前進することに関心のあるメンテナー Rustで 開発に参加し、建設に影響を与えることができる リンクを作成し、対応するインターフェースのメンテナンスを支援します。逆に、Rust を使用しないことを選択した人は、Rust の使用時に発生する可能性のある問題からは保護されますが、Rust の進化に影響を与えることもできなくなります。このアプローチは、C に専念する人々を保護する一方で、Rust 統合の改善に貢献することを妨げる一種の障壁を作り出します。

したがって、このメールは「Rust ポリシー」に関するものではありません。このメールは
もっと大きな問題:メンテナーとして、あなたは自分のコードに責任を負っている。
確かにそうですが、最終結果を誰がどのように使用するかについては、あなたが責任を負うわけではありません。

Rust が好きである必要はありません。彼のことを心配する必要はありません。それは…
最初から誰も
突然新しい言語を学ばなければならなくなり、
C 側のみで作業したい場合は、そのまま続行できます。

この状況は、ある意味では保護バリアを作り出します。C言語のみを使用する人にとっては、 複雑さやそれに伴う潜在的な欠点から彼らを切り離す Rust コードに。しかし同時に、その同じ分離により、彼らは Rust の進歩に影響を与えることができなくなり、つまり、「誰も Rust を扱う必要はない」というモットーによって、すべてのメンテナーがこの言語で書かれたコードをロックダウンできるわけではないことを意味します。

La 責任分担が組織化されている そのため、Rust に興味のある人は Rust の側面に取り組むことができ、関与しないことを選択した人は、Rust で記述されたコンポーネントの開発を変更することはできませんが、ワークフローを変更する必要はありません。

DMA サブシステムを介した Rust リンク承認の問題が発生したとき、論争は激化しました。この場合、そのようなリンクの受け入れを阻止しようとした管理者の反対は無視され、 Linus は Christoph Hellwig の行動を公然と批判した。

トルバルズ氏によれば、ヘルウィグ氏は権限を超えていたという。 別のサブディレクトリに実装されているコードに影響を与えようとしたが、そのコードは彼が担当する DMA サブシステムには影響を及ぼさなかった。 Torvalds 氏の言葉を借りれば、Hellwig 氏の態度は、単に気に入らないという理由でコントローラの DMA を無効にしようとすることに似ており、これは受け入れられない。

最終的には、各メンテナーは自分のコードに対して責任を負いますが、そのコードの使用方法を制御したり、より大きなプロジェクトへの統合を決定したりする必要はありません。