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

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

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

LinusTorvalds今晚做出了回应，他澄清说，维护者可以选择在他们监管的内核区域中积极使用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争论的现状。