在 Asahi Linux 创始人宣布辞去项目负责人职务之后，围绕 Linux 内核中 Rust 代码的争议还在继续。

DMA 映射助手及内核其他多个领域的维护者 Christoph Hellwig 一直对 Linux 内核中的 Rust 代码及其长期可维护性持批评态度，他在最新发布的一封邮件列表帖子中指出， Linus Torvalds 私下提到将推翻维护者对内核中 Rust 代码的否决权。

考虑到最近几天的讨论，我决定发布此页面，其中包含我们的理解：https://rust-for-linux.com/rust-kernel-policy……

Linus 私下表示，他绝对会不顾维护者的反对合并 Rust 代码。因此，从现在开始，作为 Linux 开发者或维护者，无论你是否愿意，都必须处理 Rust。

这里的 Rust 代码不仅仅是指 Rust 代码——这些绑定看起来一点也不像地道的 Rust 代码，它们是一种完全不同的存在，试图弥合巨大的语义鸿沟。而且它们在某些地方并没有做到这一点，因为它们现在被塞进了每个小子系统和库中。

因此，这些绑定会像癌症一样蔓延到各处，并迅速从一个允许并追求全局改进的软件项目，转向日益增加的隔离化。这将使 Linux 变成一个用多种语言编写的项目，而没有明确的指南说明在何处使用何种语言。即使在绑定之外，由于内核数据结构（如无处不在的链表）的侵入性和自引用特性，许多代码也不会是非常地道的 Rust。我们是否既对不起那些试图将现有代码库带入更安全空间的人，也对不起那些用 Rust 进行系统编程的人？

我曾经在类似的代码库上工作过，它们是我最糟糕的噩梦，因为由于原因 X，不断有部分代码从语言 A 重写为语言 B，然后又由于原因 Z 重写回去。而这还没有算上 Linux 维护者之间常见的‘创造性’内斗。

我想了解这个 Rust ‘实验’的目标是什么：如果我们想解决现有的内存安全问题，我们需要针对现有代码进行修复，并找到改进的方法。最近在这方面做了很多工作，我们还需要更多。但这也表明，核心维护者对诸如检查整数溢出或编译器强制同步（如 clang hread sanitizer)）等琐碎事情感到厌烦。我们如何弥合内核中一部分甚至不接受相对简单的安全改进规则，而另一部分却强制执行更严格规则之间的差距？

如果我们只是想使编写驱动程序更容易，那么引入一种新语言只会增加更多工作，并加重已经超负荷工作的核心基础设施维护者的负担。

因此，我认为这份政策文件没有太大用处。目前的规则是，Linus 可以强迫你做任何他想要的事情，我认为他需要非常清楚地阐明这一点，包括对贡献者的期望。

就我个人而言，我可以很好地处理 Rust 本身，我很乐意将内核带入一个更安全的内存世界，但处理一个不受控制的多语言代码库肯定会让我把业余时间花在其他事情上。我听到其他一些人嘀咕类似的话，但并不是每个人都像我这样直言不讳。

详情可查看邮件列表。