“3000万行C代码暂时不会消失，新内核驱动可用Rust写写看”，Linux二把手表态支持Rust

tayun

关于 Linux 内核的开发究竟是应该坚持使用单一的 C 语言，还是可以适当引入 Rust，一直是整个 Linux 社区悬而未决的事情。

最近，尝试将 Linux 移植到苹果自研 M 系列芯片平台的 Asahi Linux 负责人 Hector Martin，因为与反对引入 Rust 的 Linux 维护者发生了冲突，故而宣布辞去 Apple Silicon 的维护者职务，并退出 Asahi Linux 项目。随后，Nouveau 驱动程序开发人员 Karol Herbst 也因对 Linux 内核如今“有毒”的环境感到失望，辞去了 Nouveau 维护者职务...

在这一系列动荡之后，很多人认为，Linux 项目高层再不出面，恐怕 Linux 社区就要“四分五裂”了。

这不，前有 Linux 内核维护者透露，Linus Torvalds私下表示，他将不顾部分维护者的反对，继续推进 Rust 代码的合并。后就有在今日，Linux 的二把手 Greg Kroah-Hartman 出面亲自为 Rust 语言站台。在一封 Linux 内核邮件列表帖子中，Greg Kroah-Hartman鼓励大家使用 Rust 来编写新的内核代码或驱动程序，而不是继续使用 C 语言。

Linux 维护者的反对声依然在持续

带来“Linus 将推翻维护者对内核中 Rust 代码的否决权”这一消息的并非是 Linus 本人，而是 DMA 映射助手及内核其他多个其他领域的维护者 Christoph Hellwig。

Hellwig 长期以来一直对在 Linux 内核中引入 Rust 及其他次要编程语言持批判态度，尤其对 Rust 在内核中的应用表示担忧。

在 Hellwig 看来，现在很多 Rust 代码像是一个试图弥合巨大语义差距的怪物，这些“怪物”已经渗透到每一个小子系统和库中。

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

随后，Hellwig 继续补充道：

“像这样工作的代码库是我最害怕的，因为原因 X，总需要不断地从语言 A 重写到语言 B，然后又因为原因 Z 重新写回去。这还没有考虑到 Linux 中常见的‘创造性’的内斗。

我想理解这个 Rust ‘实验’的目标是什么：如果我们想修复现有的内存安全问题，我们需要为现有代码做改进，并找到方法将其改造。最近有很多工作已经投入其中，而且我们需要做更多。但这也显示出核心维护者对于检查整数溢出或编译器强制同步（例如 clang hread sanitizer）等琐事的抵触。我们该如何弥合内核的一部分不接受相对简单的安全改进规则与另一部分强制执行严格规则之间的差距呢？

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

话虽如此，Christoph Hellwig 坦言，抱怨再多其实都没有用。他补充道，Linus Torvalds 在私下里曾表示，尽管一些维护者反对，他仍然会推进 Rust 代码的合并。

也就是说，作为一个 Linux 开发者或维护者，不管是否愿意，都必须处理 Rust 代码的相关问题。

Linus 将坚持推进 Rust for Linux 项目，强制合并 Rust 内核代码

与此同时，Christoph Hellwig 还分享了一个经过 Linux 社区内部讨论而发布的一个名为《Rust 内核策略》（https://rust-for-linux.com/rust-kernel-policy#rust-kernel-policy）的页面，该页面旨在解答如何在子系统中引入 Rust、谁来维护 Rust 代码，以及维护人员是否应该以相同标准对待 Rust 代码等问题。

根据该页面内容显示，关于内核中 Rust 代码的维护，按照传统的内核维护政策，由列出的维护者负责。具体来说，Rust 子系统负责一些核心功能以及没有其他维护者的 API，但它并不承担内核中所有 Rust 代码的维护任务，因为这样做在规模上难以管理。虽然如此，团队还是愿意在需要时提供帮助，目标是通过建立一个混合团队，帮助整个内核引入 Rust。最终，Rust 子系统可能也会作为 Rust 代码的“后备维护者”，类似于 akpm 作为 C 代码的最后“救火队员”。

其次，关于 C 语言修改是否可能导致 Rust 编译失败的问题，仍然会遵循常规内核政策。默认情况下，如果已知更改会导致构建失败（包括 Rust 代码），则不应提交这些更改。然而，对于 Rust 代码，一些子系统可能允许暂时破坏 Rust 代码。这样做是为了让某些子系统能够友好地采用 Rust，同时不增加现有维护者修复 C 语言问题的负担。虽然可以暂时破坏 Rust 代码，但问题应尽快修复，理想情况下在 Linus 知道之前就解决。

再者就有现有 Linux 维护者是否应该像对待 C 代码一样对待 Rust 代码这类的态度问题，该页面写道，理想情况下，维护者确实应该按照相同的标准进行处理，但在 Rust 初步引入时，可能不必强求这一点。

此举的目的是希望 Linux 维护者不要因为觉得无法像处理 C 代码一样及时修复 Rust 代码的问题而拒绝使用 Rust。即使他们有兴趣尝试，也不应感到过大的压力。因此，根据不同子系统的情况，Rust 可能被视为一个新技术，而新技术总有可能出现问题。

然而，Hellwig 在自己发的一封帖子中明确表示，“我认为这份政策文件并不是很有用。现在的规则是 Linus 可以强迫你做任何他想做的事（毕竟这是他的项目），我认为他需要明确指出这一点，包括对贡献者的期望。对于我来说，我可以处理 Rust 本身，我也很希望将内核带入一个更安全的内存世界，但处理一个不受控的多语言代码库无疑会让我把闲暇时间投入到其他事情上。我听过一些其他人也有类似的想法，但并不是每个人都像我一样直言不讳。”

Linux 二把手：3000 万行 C 代码不会很快消失，但应该尝试用 Rust 编写新的代码和驱动程序

截至目前，Linus 并未就此事公开出面回应。不过在以《Rust 内核策略》这一邮件列表帖子讨论中，在 Hellwig 发布自己的看法不久后，素来有着“Linux 的二把手”之称的 Greg Kroah-Hartman 公开了自己的态度——支持 Rust 进入Linux 内核。

Greg Kroah-Hartman 是 Linux 内核的核心维护者之一，负责多个子系统的维护，包括驱动程序和内核稳定性方面的工作。此外，他也是 Linux 长期支持版本（LTS）的维护者之一，具有很高的影响力和权威性

Greg KH 提出，绝大多数内核漏洞都因为 C 语言中的“愚蠢的小极端情况”造成的，这些问题在 Rust 中完全不存在。他支持逐步从 C 代码库转向 Rust 代码，因为在 Rust 中，这些内存安全漏洞和 C 语言的其他不足不会发生。

Greg 承认，所有的 Linux 内核 C 代码不可能很快消失，但他确实希望新代码和驱动程序能够使用 Rust，以避免 C 语言代码中的漏洞和问题。

以下是 Greg 在 LKML 上发布的完整内容：

「作为一个过去 15 年多来几乎见证了每一个内核 bug 修复和安全问题的人（希望所有问题都能最终进入稳定树，虽然有时当维护者/开发者忘记标记为 bug 修复时，我们会漏掉一些），并且看到每一个发布的内核 CVE，我想我可以就这个话题发表一些看法。

我们遇到的大多数 bug（按数量而非质量/严重性来算）都是由于 C 语言中的愚蠢的小极端情况造成的，而这些在 Rust 中完全消失了，诸如简单的内存覆盖（虽然 Rust 不能完全捕获所有这些问题）、错误路径的清理、忘记检查错误值，以及 use-after-free 等错误。正因如此，我希望看到 Rust 能够进入内核，这些类型的问题就会消失，让开发者和维护者有更多时间去关注那些真正的 bug（即逻辑问题、竞争条件等）。

我完全支持将我们的 C 代码库逐步转向这些问题无法出现的方向，Kees、Gustavo 等人所做的工作非常棒，完全是我们需要的。我们有 3000 万行 C 代码，这些代码在未来几年内不会消失。这是一项值得的努力，不会停止，也不应该停止。

但是对于新代码/驱动程序，使用 Rust 来编写它们，因为这些类型的 bug 根本不会发生（或者发生得少得多），对我们所有人来说都是一种胜利，为什么我们不这么做呢？C++ 在未来几十年内不会给我们带来这些东西，而且 C++ 语言委员会的问题似乎也指出，如果大家想拥有一个能长期维护的代码库，就最好尽快放弃 C++。

Rust 还让我们能够以一种几乎不可能出错的方式来定义内核中的 API。我们有太多难度大、棘手的 API，维护者需要进行大量的审查，以“确保你做对了”。这是因为我们的 API 多年来不断演化（比如有多少种方法可以安全地使用‘struct cdev’？），而 C 语言无法让我们以更安全/简便的方式表达 API。迫使我们这些 API 的维护者重新思考这些 API 是件好事，因为这使得我们能够为每个人清理它们，包括 C 语言用户，这将整体上让 Linux 变得更好。

是的，Rust 绑定对我来说就像魔法一样，作为一个几乎没有 Rust 经验的人，但我愿意学习，并与那些已经站出来帮助我们的开发者一起工作。我们不能因为新证据的出现而不愿学习和改变。

Rust 并不是能解决所有问题的“银弹”，但它肯定能在许多地方提供巨大帮助。那么，为什么我们不想要它呢？

Linux 是一个每个人都用来解决他们问题的工具，我们这里有一些开发者在说：“嘿，我们的问题是，我们想为我们的硬件编写代码，而这些代码不能自动地出现所有这些类型的 bug。”

我们为什么要忽视这一点呢？

是的，我理解我们过度劳累的维护者问题（我自己也是这些人之一），但现在我们有开发者在实际做这项工作！

是的，混合语言的代码库很复杂，维护也很困难，但我们是内核开发者，靠我们，我们已经比任何人想象的更好地维护和强化了 Linux。我们把开发模型转变成了一个精密的工程奇迹，创造了其他任何人都无法做到的事情。加入另一种语言真的不应该是问题，我们过去处理过更糟糕的事情，我们不应该放弃现在确保我们的项目能够在未来 20 多年继续成功的机会。我们必须在面对新的好主意时继续前进，并拥抱那些愿意加入我们，真正做这项工作，确保我们都能一起成功的人。

谢谢！

——greg k-h 」

业界网友的看法

如今，Linux 项目高层对 Rust 语言的态度已经逐渐明朗。当然，仍有一些声音认为，接受 Rust 所带来的挑战并不值得。有些人认为，许多 Rust 所提倡的优势，其实可以通过其他方式实现。例如，边界检查和一些类似 RAII 的内存管理优化，可以在没有 Rust 的情况下通过其他工具做到，从而减少内存安全问题。此外，有人指出，Rust 代码的可读性和美观性也让人不免产生抱怨，甚至不愿被迫处理这种代码。

但更现实的是，有网友表示：“C 语言的最大问题在于后继乏人，这是 Linux 社区面临的最严峻挑战。如今，Linux 中许多 C 语言的写法已经成了‘祖传手艺’，这些特殊的用法难以接手和维护。如果没有老一辈的传承，后续开发者很难接过这个重担。换种语言，或许能为项目注入新的活力，保持长期的维护。”

尽管如此，无论是否愿意，Linux 社区似乎都需要为应用 Rust 语言而做好准备了。

参考：

https://rust-for-linux.com/rust-kernel-policy#rust-kernel-policy

https://www.phoronix.com/news/Torvalds-Override-On-Rust-Code

https://www.phoronix.com/news/Greg-KH-On-New-Rust-Code

https://lore.kernel.org/rust-for-linux/2025021954-flaccid-pucker-f7d9@gregkh/


来源：36kr