Linus Torvalds 围绕 Rust 代码明确规定了 Linux 维护者的角色

Linux 内核邮件列表中围绕内核中使用 Rust 编程语言的讨论仍在继续... Linus Torvalds 在很大程度上没有参与 LKML 围绕 Linux 内核 Rust 政策的讨论，也没有参与对 Rust 持不同意见的内核开发人员和维护人员之间的内斗。 不过今天晚上，Linus Torvalds 还是决定参与讨论。

虽然几天前有评论称 Linus Torvalds 据说他会不顾维护者的反对合并 Rust 内核代码，但在回应 Christoph Hellwig 时，他进一步澄清了自己的立场。 戴着 DMA 维护者帽子的 Hellwig 一直反对将 Rust 代码与内核中的 DMA 区域合并。

Linus Torvalds 今晚做出了回应，他澄清说，维护者可以选择在他们监管的内核区域中积极使用 Rust 绑定并参与其中，也可以采取放手不管的方式，让 Rust 与他们的代码形成互补。 但内核维护者不能反对新的 Rust 代码成为其 C 代码的有效"用户"。 Linux 内核维护者既可以参与任何拟议的 Rust 代码，也可以选择不参与，让它在内核中互补，但他们不能任意阻止它成为自己代码的用户。

“我满怀希望，并试图看看这个长线程是否会产生任何建设性的结果，但这似乎是倒退（或至少不是前进）。 事实上，您反对的拉取请求根本没有触及 DMA 层。 它实际上只是它的另一个用户，在一个完全独立的子目录中，没有以任何方式、形式或形式更改您维护的代码。 我发现你抱怨代码的新用户，然后你不断提出这些完全垃圾的论点，这让我很沮丧。 老实说，你一直在说“作为 DMA 维护者，我控制 DMA 代码的用途”。 而这并不是*任何*工作的运作方式。 接下来是什么？说特定的驱动程序不能做 DMA，因为你不喜欢那个设备，而作为 DMA 维护者，你控制谁可以使用 DMA 代码？ 这正是你正在尝试的与 Rust 代码有关。 你说你不同意 Rust——这很好，没有人要求你编写或阅读 Rust 代码。 但是你采取这种立场意味着 Rust 代码甚至不能使用或与你维护的代码交互。 所以让我非常清楚：如果你作为维护者觉得你控制着谁或什么可以使用你的代码，那你就错了。 从技术上来说，我尊重你，我喜欢和你一起工作。 不，我不是在寻找唯唯诺诺的人，我喜欢你指出我的胡言乱语。我有时会说一些蠢话，需要有人站出来告诉我我在胡说八道。 但现在我要指出你的*你的*。 所以这封电子邮件不是关于一些“Rust 政策”。这封电子邮件是关于一个更大的问题：作为维护者，你负责你的代码，当然——但你不负责谁使用最终结果以及如何使用。 你不必喜欢 Rust。你不必关心它。这一点从一开始就很清楚，没有人会被迫突然学习一门新语言，那些想纯粹在 C 端工作的人完全可以继续这样做。 所以回到你声明的核心： “文档声称没有子系统被强迫采用 Rust” 这是非常正确的。 你没有被强迫采用任何 Rust 代码，或关心 DMA 代码中的任何 Rust 代码。你可以忽略它。 但“忽略 Rust 方面”也自动意味着你在 Rust 方面没有任何发言权。 你不能两全其美。你不能说“我不想和 Rust 有任何关系”，然后在下一句话中说“这意味着我将忽略的 Rust 代码不能使用我维护的 C 接口”。 想要参与 Rust 方面的维护者可以参与其中，通过参与其中，他们将对 Rust 绑定的外观有一定的发言权。他们基本上也成为 Rust 接口的维护者。 但选择“我不想处理 Rust”选项的维护者基本上也不必为 Rust 绑定操心 - 但结果他们也不会对 Rust 方面发生的事情发表任何意见。 因此，当您更改 C 接口时，Rust 人员将不得不处理后果，并且必须修复 Rust 绑定。这就是这里的一种承诺：在承诺他们不必处理 Rust 问题的情况下，围绕不想处理 Rust 问题的 C 开发人员有一道“保护墙”。 但那道“保护墙”基本上是双向的。如果您不想处理 Rust 代码，您就对 Rust 代码没有任何发言权。 换句话说：“没有人被迫处理 Rust”并不意味着“每个人都可以否决任何 Rust 代码”。 看到了吗？ 不，我实际上并不认为这需要那么黑白分明。我已经用非常黑白分明的术语陈述了上述内容（“也成为 Rust 绑定的维护者”与“根本不想处理 Rust”），但在很多情况下，我怀疑这将是一条不那么苛刻的界线，子系统维护者可能*知道* Rust 绑定，并愿意与 Rust 方面合作，但可能不会积极参与。 所以它真的不必是“全有或全无”的情况。 Linus”

这就是 Linux 内核代码 Rust 争论的现状。