↓推荐关注↓
自 Linux 内核长期以来由 C 语言构建起步，直到 Rust 这股新兴力量悄然涌入，编程语言之争这把“火”，现如今不仅“烧”到了全球主流开源操作系统 Linux 的中心，还将 Linux 原有的维护者与 Rust 开发者推向了前所未有的对立面。
在一些 Rust 开发者看来，Rust 是安全语言的象征，在 Linux 内核中引入此语言无疑可以提高系统的性能、安全性。
然而，这一说法并未得到 Linux 内核维护者的认可，他们反而担心，多种语言的使用会让这个超级开源项目的维护变得更加困难，其甚至直言——Rust 与 C 语言的混合代码在 Linux 中就是“癌症”。
争论之下，Linux 之父 Linus 出面回应、核心开发者愤而辞职选择从此视而不见听而不闻...
Linux 内核维护者 vs Rust 开发者的口舌之争
其实 Rust for Linux 项目推进起来已有几年的时间，此前在 Linux 6.13 内核的“char/misc”模块合并中，新增了对 Rust 的支持，使得开发者能够使用 Rust 编写 misc 驱动程序，这是一些良好的开端。
不过，期间也出过一些“意外”，如去年 9 月，微软软件工程师也是 Rust for Linux 的核心维护者 Wedson Almeida Filho 官宣自己退出 Rust for Linux 这一项目，给出的理由是——已经疲于应对社区内越来越多与技术毫无关系的“废话”了，但好在此后项目仍在持续推进。
至于此次如文章伊始所述的 Linux 内核维护者和 Rust 开发者公然“互怼”又是为哪般？
具体看来，还是因为一场技术争议引发的口舌之争。
就在上个月，有人在 Linux 内核中带来了一个提案——想让用 Rust 写的设备驱动能够调用 Linux 内核中用 C 写的一个重要功能（DMA）。
具体来说，在 Linux 系统中，设备（比如网卡、显卡等）有时需要直接访问计算机的内存，而不经过 CPU 的干预。这种方式叫做直接内存访问（DMA, Direct Memory Access）。为了让设备能够使用 DMA，操作系统需要做两件事：
分配一块内存：这块内存是设备可以直接访问的。
映射这块内存：告诉设备这块内存的物理地址，这样设备才知道去哪里读写数据。
在 Linux 内核中，有一个专门的 API 叫做 DMA API，它提供了一些函数来帮助完成这些任务。其中一个重要的函数是 dma_alloc_coherent()，它的作用是：
分配一块内存，并且保证这块内存是“连续的”（设备通常需要连续的内存块）。
同时，它会把这块内存的物理地址映射给设备，这样设备就可以直接访问这块内存了。
基于此，有人在 Linux 内核中提交了一个补丁，目的是让 Rust 编写的驱动程序也能使用这个 dma_alloc_coherent() 函数，这样 Rust 驱动程序也能像 C 语言编写的驱动程序一样，使用 Linux 内核提供的 DMA 功能，从而更高效地处理设备与内存之间的数据传输。
然而，这个提议遭到了 Linux 内核维护者 Christoph Hellwig 的强烈反对。Hellwig 明确表示，他不希望在内核的 DMA 部分看到 Rust 代码。
实际上，这个补丁只是将代码添加到了一个不同的地方（rust/kernel），而不是直接改动 DMA （kernel/dma）部分。
Hellwig 的拒绝让很多 Rust 开发者们感到郁闷，对此，Rust for Linux 项目的首席开发者 Miguel Ojeda 出面请求 Hellwig 给出一个替代方案。
Hellwig 回应道：“把包装器放在你们自己的代码里，而不是让别人为你们的事情受苦。”
因为是在邮件列表的回应，所有开发者都可以看到，对此，Red Hat 的软件工程师 Danilo Krummrich 直接质问 Hellwig，「你们自己的代码是什么意思？是不是在每个驱动程序中都重复了？否则，rust/kernel/dma.rs 看起来合理，对吧？」
Hellwig 接着表示：“DMA API 的接口应该保持在可读的 C 代码中，而不是用奇怪的绑定来实现，这样它才可以被 grep 搜索并且更易于维护。”
此外，Hellwig 也明确表示他根本不愿意处理 Rust 代码。他写道：“不要强迫我处理你们这门时髦的语言。维护多语言的项目很痛苦，我没有兴趣去处理。如果你们想用的不是 C 语言，像汇编语言或 Rust，你们自己写 C 接口，自己解决语言不匹配的问题，反正我不管。”
Red Hat 的软件工程师 Danilo Krummrich 解释称，并没有人要求你处理或者维护这段 Rust 代码。Rust for Linux 项目正在创建 Rust 代码，它将 C API 抽象化，供所有 Rust 驱动程序使用，并由 Rust 开发者来维护。
换句话说，内核中的 C 代码保持不变，而 Rust 驱动程序通过抽象层来使用这些 C 代码，这些抽象层由 rust/kernel 中的团队集中维护，整体上比每个驱动程序自己编写 C 语言绑定要好。
但 Hellwig 似乎不愿意让 DMA 的 Rust 抽象层单独维护，甚至不应该在 Linux 源代码树 rust/kernel 中维护。他怒斥道：
“如果你们想让 Linux 因为跨语言的代码库变得无法维护，那就让你们的驱动自己去做吧，而不是把这种‘癌症’传播到核心子系统中。（这里说的‘癌症’显然是指跨语言的代码库，而不是 Rust 本身，只是为了避免被激起争议）”
此话一说，这让人想起 2001 年，前微软 CEO 史蒂夫·鲍尔默曾将 Linux 比作癌症。他当时说：“Linux 就像一种癌症，它会在知识产权的层面附着到它接触的每一个东西。”那时 Linux 还没有扩展到 Windows 子系统中。而现如今 Windows 开始深度集成 Linux 子系统，微软深度拥抱了开源。
Hellwig 继续论述说，让其他人单独维护 Rust 的抽象层来处理 DMA 的内存分配器，并不会改善问题，反而会妨碍内核的可维护性：
“每引入一种新语言，就会大大降低内核作为一个整体项目的可维护性。Linux 之所以能生存这么久，是因为它没有内部边界，而引入另一种语言完全破坏了这一点。你可能不喜欢我这么说，但我会尽全力阻止这种做法。这不是因为我讨厌Rust。虽然它不是我最喜欢的语言，但它绝对是新兴语言中最好的之一，我鼓励人们在适合的情况下用于新项目。我只是不希望它出现在我需要维护的大型 C 语言代码库中。”
几轮辩论之后，Red Hat 的软件工程师 Danilo Krummrich 认为：
Hellwig 作为一名维护者，他的一些举措超出了维护者的工作范围，即：
根据个人喜好，任意限制某个实体对公共内核 API 的使用。
为此，他和 Asahi Linux 项目负责人 Hector Martin 纷纷请求 Linux 之父 Linus Torvalds 出面解决这一问题。
Asahi Linux 项目负责人 Hector Martin 在邮件中写道：
我的看法：如果 Linus 没有在这个讨论中给出权威的答复，Miguel 和其他 Rust 的开发者应该在代码经过审查并准备好后，直接合并这部分内容，不必理会 Christoph Hellwig 明显想要破坏项目的行为。
如果 Linus 拒绝合并，那么 Christoph 说的就无关紧要了。
如果 Linus 不合并，R4L 项目基本上就会死掉，除非 Linus 或 Christoph 采取行动。其他的讨论只是绕圈子。
Rust 开发者们：请不要浪费时间和精力去纠结这种戏剧性的事情，这不值得。要么 Linus 喜欢，要么他不喜欢。其他的都是少数破坏者维护者故意制造的干扰，他们想通过打击你们的士气来让你们放弃，因为他们知道自己终究会在历史中处于失败的一方。旧的固守阵地的维护者再怎么破坏，也无法阻止世界向内存安全语言的方向发展。
顺便说一句，我认为 Christoph 的“癌症”言论足以成为违反行为规范的理由，但我怀疑不会有任何相应的处理。
Linus 回怼：我根本不想参与你的社交媒体舆论战
殊不知，Hector Martin 的这一则邮件直接将 Linus 推到需要做出二选一决策的”边缘“。
面对 Hector Martin 呼吁 Linus “发表权威回答”以解决设备驱动的僵局，并支持通过“社交媒体羞辱”来反击 Linux 维护者对 Rust 代码的敌视，Linus 对此方法予以否定。
Linus 极其礼貌但毫不客气地回应 Martin：
如果在社交媒体上羞辱他人没有效果，那就告诉我，还有什么方法有效，因为我已经没有其他办法了。
你能不能接受一个事实，也许问题出在你自己身上？
你以为你知道得更好，但目前的流程是有效的。
它有问题，但问题是生活的一部分。没有完美的东西。
不过，我必须说，社交媒体的“围攻”让我根本不想再和你们的做法有任何关系。
因为如果我们在内核开发模式中有问题，那么社交媒体绝对不是解决方案。就像它根本不是政治问题的解决方案一样。
技术补丁和讨论才是关键。社交媒体围攻——谢谢，但不需要。
Asahi Linux 首席开发者 Hector Martin 辞去上游 Apple Sillicon 维护者职务
在得到 Linus 的回复之后，Hector Martin 愤而决定辞去 Apple Silicon 代码的上游维护者职务。
Hector Martin 在最新的一次补丁中写道：
“我已经不再对内核开发过程或社区管理方式抱有任何信心。
Apple/ARM 平台的开发将继续在下游进行。如果未来我有兴趣向上游提交一些补丁，不管是针对哪个子树，我可能会，也可能不会。任何愿意自己为上游提交做出努力的人都可以去做。”
Hector Martin 看起来似乎不打算再直接为上游 Linux内核贡献代码，而是只专注于 Asahi Linux 的下游代码。
相信使用 macOS 系统的开发者对于 Asahi Linux 这个项目也并不陌生，它是一个旨在将 Linux 移植到搭载 Apple Sillicon 芯片上 Mac 的计划，使苹果的系统可以运行 macOS 以外的操作系统。
现下随着 Hector Martin 辞职，其他人可能会接手处理补丁，以努力将其提交到上游。Asahi Linux 的开发者兼共同维护者 Sven Peter 听闻这一消息后出面表示：“给我几天时间来弄清楚我们该怎么做。我认为我们可以继续推动该树的前进。”
但无论如何，这些关于上游 Linux 内核邮件列表的争论并不利于推动 Apple Silicon 的支持，尤其是对于那些希望在 Apple Mac 上看到 Linux 的用户，而不仅仅是在 Asahi Linux 的框架下。
Linux 中的 Rust、C 之争依然在持续
社区的动荡必定会影响到技术的稳定发展。回看 Linux 内核自 2022 年开始整合 Rust 代码，但它仍然是一个以 C 为主的代码库。许多 C 语言程序员明确表示，他们不会因为 Rust 的崛起而改变自己的方式。而 Rust 的忠实使用者则认为，Rust 代码可以避免 C 和 C++ 中常见的内存安全问题（如缓冲区溢出），这些问题构成了大部分大规模项目中的严重漏洞。
在引入 Rust 的过程中，C 和 Rust 开发者之间的摩擦也是不可避免的，Linux 的创始人 Linus Torvalds 也对此有深刻认识，他曾在 Linux 基金会的开放源代码峰会上提到过这一点。
Torvalds 说：“显然，有些人就是不喜欢 Rust，也不希望 Rust 侵犯他们的领域。有人甚至在说 Rust 的整合是失败的……我们做这个已经好几年了，现在说失败还太早，但即使它最终失败了——虽然我不认为会失败——那也是一种学习的方式。”
此外，他还指出，目前内核中的任何功能都不依赖 Rust，短期内也不会依赖。重要的是向前推进，因此开发者们应该“全速前进”，暂时不要太在意这些问题。即便现在细节还不完善，只要能让功能正常运行就足够了。一旦用户开始依赖 Rust 代码，才需要更细致地处理这些问题。但现在，如果开发者因为过于谨慎而裹足不前，反而会让项目受挫。
只是在此次争论中，Linus 的处理方式让不少开发者觉得有些不满：
Rust 问题暴露了 Torvalds 作为领导者的一次罕见失职。与其果断地说“不是，绝对不行”或者“是的，执行”，他在 Rust 的问题上一直模棱两可。鉴于 Linux 社区中有相当一部分（且非常 vocal）的人对他的决定产生了信任危机，这种犹豫不决的态度反而起到了适得其反的效果。而且 Linus 没有明确立场，实在是有些反常（比如我们都知道他对 C++ 的立场）。
作为一个试点项目，R4L 应该早就毕业或者结束了。但经过多年积极开发，它的现状依旧不明朗。Linus 并没有采取措施让大家达成共识，而是选择一直坐视不管，看着下属们相互争斗，最后还将责任推给 Martin，实在是欠妥。
可以说，他对 Martin 的训斥明显表明了他永远不会偏袒 Rust，但他并没有明确说出来。也许他知道应该表态，但又担心会引发一场风暴。也许现在是时候撕掉创可贴了。
再说一次，所有这些本来都可以避免，如果他当初能坚定地站队，不论是赞成还是反对。想象一下，如果 Linus 直接说“不要，保持在下游”，能节省多少时间和精力，甚至是仅仅 Martin 的时间。
对此，你怎么看？
来源：
https://news.ycombinator.com/item?id=42972062
https://www.phoronix.com/news/Asahi-Linux-Lead-No-Upstream
https://www.theregister.com/2025/02/05/mixing_rust_and_c_linux/
https://lore.kernel.org/lkml/Z5qeoqRZKjiR1YAD@pollux/
1、C++训练营，来了！
2、HarmonyOS 学习资料分享（无套路免费分享）
我组建了一些社群一起交流，群里有大牛也有小白，如果你有意可以一起进群交流。
欢迎你添加我的微信，我拉你进技术交流群。此外，我也会经常在微信上分享一些计算机学习经验以及工作体验，还有一些内推机会。
加个微信，打开另一扇窗
感谢你的分享，点赞，在看三连
