Linus 将不顾反对合并 Rust 代码？！内核维护者无奈强调：不能让“癌症”扩散！

自从 2022 年 Rust 代码首次被合并到 Linux 内核中，围绕它的争议就不断升温。Rust 因其在内存安全方面的优势而备受推崇，也被各国政府和安全专家认为能够有效减少由于内存安全漏洞导致的高危安全问题。

近段时间以来，围绕在 Linux 内核中引入 Rust 语言的讨论愈演愈烈。

本周，一直以来对 Rust 持质疑态度的 Linux 内核关键维护者 Christoph Hellwig 在 Linux 内核邮件列表上的一条讨论线程中无奈披露，Linus Torvalds 私下说过，他绝对会不顾维护者的反对，合并 Rust 代码。

Hellwig 直言：“所以从现在开始，作为一名 Linux 开发者或维护者，你想接受 Rust 也好，不想接受也罢，都必须去面对它。”

与此同时，Linux 核心内核开发者 Greg Kroah-Hartman(下称 Greg K-H) 也再次呼吁社区接纳那些愿意贡献 Rust 代码以改进内核的开发者。他本周三在邮件中写道：“没错，混合语言的代码库确实很棘手，也很难维护，但我们是内核开发者啊。我们维护和强化 Linux 的时间比任何人最初的预期都要长。”

Greg K-H 进一步表示，“我们把开发模式打磨成了精细运转的工程奇迹，创造了前所未有的成果。”“再添加一种新语言不应该成为问题。相比之下，我们过去克服过更棘手的挑战，现在更不应该让项目在未来 20 多年继续成功的道路上退缩。面对新的好想法，我们必须继续前进，并欢迎那些愿意一起真正投入工作、帮助我们共同成功的人。”

Hellwig 和 Greg K-H 发表这些内容的背景，源于上个月在社区中的多轮激烈争论。

当时 Rust for Linux（R4L）项目提交了一则补丁，允许使用 Rust 编写的设备驱动去调用主要用 C 语言编写的内核的核心 DMA API，却遭到 Linux 内核维护者 Christoph Hellwig 的质疑。Hellwig 将维护多语言代码库比作“癌症”，强调自己无意承担维护 Rust 设备驱动代码的负担。紧随其后的争论引发了时任 Asahi Linux 项目负责人的 Hector Martin 的不满。他要求 Linus Torvalds 表态，是否会将这个补丁合入内核。

最终， Linus 并没有给出补丁去留的明确裁定，而是批评 Martin 在社交媒体上就此事“作秀”，并为 Linux 社区的治理模式辩护。Hector Martin 称，这成为“压倒他的最后一根稻草”。随后，Martin 辞去了 Linux 维护者一职，并离开了 Asahi Linux 项目，不再负责 Linux 内核 Apple Silicon 代码的上游维护工作。

延展阅读：《Rust 补丁两年零通过，34年开发者煽动网友逼Linus表态，维护者激烈反击：Rust 就是 Linux 的“癌症”！》

多语言混编“像癌症”蔓延

在最新的邮件中，Hellwig 再次表达了对在同一个代码库中混合使用 Rust 和 C 的担忧。他警告称，如果在没有明确政策和广泛讨论的前提下就把 Rust 代码大规模合并到内核的各个子系统里，会令后续维护者疲于奔命。这种“多语言混编”也会影响对旧代码的全局性改进。

“我曾在混合语言的代码库上工作过，那简直是我的噩梦：因为各种原因，会把部分代码从语言 A 重写成语言 B，然后又因为原因 Z 再转回 A，这种折腾不断。而这还没算上 Linux 社区平时常见的内斗纷争。”

Hellwig 强调，C 和 Rust 之间存在巨大语义鸿沟，给内核基础组件做互操作需要大量的“胶水”或绑定层。一旦绑定（bindings）分散到各个子系统，就像“癌症”一样随处扩散，最终造成对核心基础设施的重复改写与无法预期的复杂度。

为安抚内核开发者社区，目前 Rust for Linux 项目和 Linux 内核维护工作的贡献者 Miguel Ojeda 发布了所谓的 “Rust kernel policy”（Rust 内核策略），但并未将其纳入内核代码库。

Rust kernel policy：https://rust-for-linux.com/rust-kernel-policy

Hellwig 质疑，这个文档只发布在网络上，而非放入内核代码树中，“所以我并不觉得这份‘政策’文档有什么实际价值。”“就我个人而言，我对 Rust 语言本身没问题，也能用它。我也很希望看到内核能更安全。但是，在一个无法控制的多语言代码库里工作，几乎可以肯定会让我把业余时间花在别的事情上。我听到有些人也在小声嘀咕类似的想法，只是大家没我这么直白而已。”

因此，Hellwig 强调，如果真正想解决内存安全问题，就应该在现有 C 代码上做更多防护、审查与修复，而不是把希望全部寄托在换语言上。他还提到，社区已经在做“编译器强制同步检查”或“整数溢出检查”等工作，但推进并不顺利，因为部分开发者或维护者对这类改动都尚有抵触，何况是引入另一种语言。

总之，Hellwig 认为，现在的现状是：Linus 想做什么就可以强行做什么（这毕竟是他的项目），但他觉得 Linus 需要把这些事情说清楚——包括对贡献者的期望等等，都要讲得非常明白。

让 C 更好的优化工作不会停止

在 Hellwig 披露 Linus 态度的同时，另一位“重量级”内核维护者 Greg K-H 却持截然不同的观点。一直以来，Greg K-H 都倾向于支持引入 Rust ，本周他在邮件中也再次讨论了关于 Rust 和内存安全的争议。

“我们遇到的大多数（按数量而不是质量或严重程度来算）漏洞，都是源于 C 中那些愚蠢的小角落，而这些问题在 Rust 中完全不存在，”他写道。

“比如简单的内存越界写入（并不是说 Rust 能捕捉所有类似问题）、错误处理路径的清理、忘记检查错误返回值，以及使用已释放的资源等。这些正是我想在内核中引入 Rust 的原因：这些问题会直接消失，让开发者和维护者能够把更多时间投入到真正的错误上（比如逻辑问题、竞争条件等）。”

Greg K-H 进一步表示，他同样支持让 C 代码变得更健壮，这方面的工作并不会停止。“但是对于新的代码和驱动来说，用 Rust 编写可以杜绝（或大大减少）这些类型的错误，这对我们所有人来说都是好事，我们为什么不这么做呢？”

“C++ 在未来十年也无法为我们提供这方面的帮助，而且根据最近 C++ 语言委员会的讨论来看，如果你希望代码库能长期维持可维护性，那么最好尽快放弃 C++ 。”

当然，他也承认 Rust 并不是银弹，不会魔法般地解决所有问题。但他坚信这会有所帮助。

维护者倦怠与开源生态的挑战

两周前辞去了内核维护者一职的 Hector Martin 认为，为了生存，Linux 需要主要利益相关方的支持，但 Linus 的“放任”态度让子系统维护者可以阻挠并滥用其他贡献者，打击社区士气却毫无后果。他举了一个例子：Rust for Linux 维护者、微软软件工程师 Wedson Almeida Filho 曾于今年 8 月辞职（离开 R4L），这在社区内广受关注。

确实，Linus 本人也曾在与贡献者互动时显得言辞尖锐。比如去年，他曾对谷歌的一名开发者说：“你的代码就是垃圾（your code IS GARBAGE）。” 和 Martin 的情况类似，这也引发了开源社区“维护者倦怠”的讨论。

开源社区的“维护者倦怠”（burnout）已是老生常谈。原因包括高强度的义务劳动、激烈的人身攻击、缺乏对志愿者工作的认可，以及超负荷的工作量等。Rust 语言工程师 Jynn Nelson 去年也曾指出，“因为倦怠而离开 Rust 项目的人数之多令人震惊，而仍处在倦怠边缘的人数也同样惊人。”

Sonatype 联合创始人兼 CTO Brian Fox 近期接受技术媒体 The Register 采访时表示，“开源软件的开发者正以惊人的速度出现倦怠，这对软件供应链安全构成威胁。……那些被遗弃或维护不善的旧软件会留下巨大的安全漏洞。”

“我们最近发布的《软件供应链现状》报告发现，自 2020 年以来，开源项目更新频率陷入停滞或下降，这表明这些非营利性的维护者正面临倦怠或资源短缺，”他说，“到 2024 年，将有超过 30 万个项目的发布节奏放缓或停滞。”

Fox 认为，一个健康的软件生态系统需要一个运转良好的社区，而这需要资金来支持。“为项目维护者提供薪酬并雇佣更多开发者是一个好的开始；考虑到很多项目是由非营利基金会维护的，下游的主要用户也应该联合起来提供资金支持这些开源项目。”

当然，资金并非一切。Martin 称，他曾试图通过限制自己对内核上游维护的投入来避免倦怠。但去年，他经历了一系列个人挑战，其中包括“不得不应对各类骚扰者和跟踪者，他们对我和我的家人进行骚扰和攻击（并且仍在继续）。”

Martin 还表示，他之所以决定离开 Asahi Linux 和 Linux 内核社区，部分原因是感到自己被“背叛”：

“在（Linus 对我批评）之后的几天里，我得知一些内核和相关 Linux 圈子里的人一直在对我玩弄两面派手段，他们表面上对我和 Asahi Linux 表现出支持，私底下却对我心生抵触，并在背后煽动抵触情绪，”他说，“这一切都发生在完全没有任何人私下写邮件或以其它方式向我透露任何信息的情况下。我还听说，其中有一位在多个 Asahi Linux 生存所必需的项目中都身居高位的成员，竟然站在曾经直接伤害和骚扰我的人那边，并继续支持他们。”

参考链接：

https://www.theregister.com/2025/02/21/linux_c_rust_debate_continues/

https://www.theregister.com/2025/02/11/rust_for_linux_project_support/?td=keepreading

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

https://lore.kernel.org/rust-for-linux/Z7SwcnUzjZYfuJ4-@infradead.org/