系列文章《内核江湖》第 1 篇 · 神仙打架
从 2021 年一个 Google 工程师提交的 RFC，到 2025 年 Android 16 搭载 Rust 编写的内核模块出货——这不是一个关于编程语言的故事，而是一个关于"谁有权改变世界"的故事。
"The problem with C is that it makes it too easy to shoot yourself in the foot."
—— Bjarne Stroustrup
（C 的问题是它让你太容易搬起石头砸自己的脚。）
1. 故事引入
2025 年 1 月，一个 PATCH 系列在 linux-iommu 邮件列表上引发了长达 41,667 词（英文）的讨论——LWN 用整篇超长文报道了这件事。导火索是这样的：有人想给 Linux 内核的 DMA 映射层加一个 Rust 封装，好让 Rust 驱动能做直接内存访问。
DMA（Direct Memory Access）是几乎所有设备驱动的刚需——网卡收包、显卡渲染、SSD 读写，都离不开 DMA。简单说，DMA 让外设直接在内存和自己之间搬运数据，不经过 CPU。没有 DMA，你的设备驱动基本是废的。换句话说，不搞定 DMA，Rust 写驱动就是纸上谈兵。
DMA 映射领域的核心开发者 Christoph Hellwig 的回应简洁而决绝：
Keep the wrappers in your code instead of making life painful for others.
（把封装放到你自己的代码里，别给别人添堵。）
不是"我们再讨论讨论"，不是"技术上有些顾虑"，而是——别来。
这封邮件成了整场 Rust-in-kernel 争论的缩影：一边是 Rust 阵营的急切推进，一边是老派维护者的生硬抵制。但如果你以为这只是"谁的编程语言更好"的技术讨论，那你把这件事看得太简单了。
这场争论从 2021 年一个 RFC 开始，到 2025 年 Android 16 出货时搭载了 Rust 编写的内核模块，牵涉的人物从 Linus Torvalds 到 Google 工程师到澳大利亚麻醉科医生风格的独立开发者——故事远比你想的曲折。
2. 背景铺垫
在讲这场冲突之前，得先理解一件事：Linux 内核已经有 30 多年历史了，用 C 语言写的。整个项目有超过 3000 万行代码，由全球数千名开发者协作维护。它可能是人类历史上最大规模的协作软件项目。
C 语言的优势在于——它就是"系统编程"的定义本身。内核开发者用 C 写了几十年代码，每个子系统都有自己的维护者（maintainer），每个人都在自己的领地里耕耘。代码审查、API 设计、错误处理……所有的一切都是围绕 C 的工作方式建立的。
内核的权力结构可以简单理解为：每个子系统有一个 maintainer，他对自己的代码有绝对的话语权。你想改他的代码？先说服他。他不同意？Linus 可以介入，但 Linus 通常尊重 maintainer 的判断。这套系统运转了几十年，虽然偶有摩擦，但大体上是稳定的。
然后有人提议：我们应该也用 Rust。
Rust 是 Mozilla 在 2010 年代开发的系统编程语言，主打"内存安全"——编译器在编译阶段就能拦住大量 C 语言中臭名昭著的 bug：use-after-free（释放后使用）、double free（重复释放）、数据竞争等等。这些 bug 是内核安全漏洞的重灾区。对于一个每年要修几百个安全漏洞的操作系统内核来说，这听起来简直是天降甘露。
但问题从来不是"Rust 技术上行不行"。
问题是——你让一群用 C 写了 20 年代码的人换一种语言，这不仅仅是学新语法的问题。这是在动摇他们对自己代码的控制感。当 Rust 代码要进入你的子系统时，你至少需要能读懂它——而你可能从来没碰过 Rust。
说白了，这场争论的真正核心不是"Rust vs C"，而是"变革 vs 守成"——是人类对所有重大组织变革都会产生的本能抵抗。
3. 故事主线
3.1 第一幕：一个 Google 工程师的疯狂提案
2021 年 4 月 14 日，Rust-for-Linux 项目领导者 Miguel Ojeda 向内核邮件列表提交了 13 个补丁的 RFC（Request for Comments）系列，标题是 [RFC PATCH 00/13] [RFC] Rust support。项目核心实现者、Google 工程师 Wedson Almeida Filho 同日在 Google 安全博客上发文介绍了这个项目。
这不是一个"建议讨论 Rust"的邮件。这是一套完整的、可编译的 Rust 内核支持层——包括 Rust 语言的基础设施、与 C 代码的 FFI 绑定、以及一个实际的驱动示例：Android 的 Binder IPC 机制的 Rust 实现。
Binder 是 Android 系统中最关键的进程间通信机制。每个 Android app 和系统服务之间的通信都要经过它。它也是内核中最臭名昭著的代码之一——用 C 写的，充满手动内存管理，历史上出过大量安全漏洞。Google 有充分的理由想用更安全的语言重写它。
Wedson 在邮件中写道：
We admittedly don't have a huge number of wrappers yet, but we do have enough to implement most of Binder and so far it's been ok.
（我们的封装确实还不多，但已经足够实现 Binder 的大部分功能了，到目前为止还算顺利。）
Wedson 在 2021 年 7 月回复 Christoph Hellwig 的质疑时，解释了为什么选择 Binder：
Miguel's point is that it does implement the vast majority of binder features and is non-trivial, so it could be used as evidence that useful kernel drivers can be built with Rust; not just "transpiled" from C, but written with the Rust safety guarantees.
（Miguel 的观点是，它实现了 Binder 的绝大部分功能，而且并非简单的模块——它可以作为证据，证明用 Rust 能构建出有用的内核驱动；不仅仅是从 C "翻译"过来，而是真正利用了 Rust 的安全保证。）
换句话说，Binder 是一个完美的"压力测试"：它复杂到能证明 Rust 的价值，又足够重要到让 Google 投入资源。2023 年 11 月，Alice Ryhl 正式提交 Rust Binder RFC 时更明确地总结了三个原因：复杂度（6kLOC 代码中嵌套了 13 种锁、7 个引用计数）、技术债（千行函数、容易出错的错误处理）、安全关键（Android 沙箱的核心组件）。
当时内核社区的反应是……谨慎的好奇。Peter Zijlstra（调度器核心维护者）问了一些深入的技术问题，Greg KH 询问了测试覆盖情况。有人担心编译器版本要求太高，有人质疑学习成本。但没人直接说"不行"。
毕竟，这只是一个 RFC——征求意见而已。
2021 年 7 月，v2 版本发布——17 个补丁，更完善了。2021 年 12 月，Wedson 单独把 Binder 的 Rust 实现作为 RFC 发出（[RFC PATCH 19/19] drivers: android: Binder IPC in Rust），明确告诉社区：这不是一个玩具项目，这是一个真实驱动的真实重写。
3.2 第二幕：从 RFC 到合入——实验的开始
接下来的一年半，Wedson 和 Miguel Ojeda（Rust-for-Linux 项目的领导者）在邮件列表上一轮又一轮地提交补丁。每一轮都比上一轮更精炼，封装层更完善，反对意见更少。
Miguel Ojeda 是这个项目的灵魂人物。他不是 Google 员工（当时不是），而是一个西班牙的独立开发者。他以极高的耐心和外交技巧处理了邮件列表上的每一条反对意见——这在内核社区是一种稀缺技能，因为很多技术争论最终都会变成互相大喊大叫。
2022 年 10 月，Linux 6.1 的合并窗口期。Linus Torvalds 拉入了 Rust 的基础支持。不是完整的驱动框架，不是 Binder，只是一些基础设施——让内核能用 Rust 编译器构建出最基础的模块。
LWN 报道了这次合入（#910762: A first look at Rust in the 6.1 kernel），标题用了"first look"——第一次认真审视。
这不是一个"我们决定用 Rust"的宣言。Linus 给它贴了一个标签：实验（experiment）。
如果事情不顺利，Rust 会被移除。
这个标签既是保护伞，也是紧箍咒。保护伞——给了 Rust 推进者试错的空间，反对者不能说"这太冒险了"因为反正可以回退。紧箍咒——每一个反对者都可以说"这还是个实验，凭什么让我们学？"
2023 年 3 月，6.3 内核加入了更多 Rust 支持——但 LWN 的报道标题是 Kernel time APIs for Rust，一个小而重要的 API，暗示了进展的缓慢。正如报道所说：
It still remains true that there is little that can be done in Rust beyond the creation of simple modules.
（目前用 Rust 能做的事情仍然很少，除了创建简单模块之外。）
3.3 第三幕：文化战争
实验推进的速度比预期慢。慢的原因不是技术，而是人。
2024 年 9 月的 Maintainers Summit 上，Rust 再次成为焦点。Greg Kroah-Hartman（stable 内核维护者，内核社区最有影响力的人物之一）说了一句关键的话：
It is clear at this point that Rust in the kernel is viable.
（到目前为止，Rust 在内核中的可行性已经很清楚了。）
但并不是所有人都这么看。一个至今仍在争论的核心问题被正式摆上了台面：如果 C 侧的接口改了，谁来修 Rust 的代码？
这个问题听起来很技术，但本质上是一个权力问题。C 维护者改了自己子系统的接口，发现 Rust 的绑定编译不过了——是 C 维护者来修，还是 Rust 开发者来修？
Linus 的回答很明确：
Nothing depends on Rust in the kernel now, and nothing will for some time yet. What is important is to make forward progress, so developers should "steam right ahead" and not worry about these problems for now.
（现在内核中没有任何东西依赖 Rust，短期内也不会有。重要的是向前推进，所以开发者应该"大踏步前进"，暂时不用操心这些问题。）
Linus 还说了一句让所有人安心的话——当有人问"如果某个子系统阻挠进度怎么办"时，他回答：
That's my job.
（那是我的工作。）
简单来说：如果 maintainer 不合理地阻挠 Rust，Linus 会介入。
Thomas Gleixner（实时内核维护者，内核社区最有经验的开发者之一）提供了一个深刻的历史类比：
20 years ago, there had been a lot of fear and concern surrounding the realtime kernel work; he is seeing the same thing now with regard to Rust. We cannot let that fear drive things.
（20 年前，围绕实时内核工作也有大量的恐惧和担忧；他在 Rust 上看到了同样的事情。我们不能让恐惧驱动决策。）
说白了，PREEMPT_RT（实时内核补丁）从 2004 年开始开发，花了 20 年才基本合入主线。用 Clang 编译内核花了 10 年——"and that was the same old language"（而且那还是同一门语言），Linus 说。同一门语言尚且如此，换一门语言的阻力可想而知。Rust 才两年，Linus 说——"nothing"。
但文化冲突还有一个更尖锐的侧面。社区里一直在传一句话，据说是某个维护者说的：
You're not going to make us learn Rust.
（你不可能逼我们学 Rust。）
这句话后来被反复引用，成了 Rust 反对阵营的代名词。不管它是不是被断章取义，它准确地表达了很多人的真实担忧：他们不想被迫学一门新语言来维护自己写了十年的代码。
Ted Ts'o（ext4 文件系统维护者，内核社区最受尊敬的人物之一）的态度转变很有代表性。2024 年的 Maintainers Summit 上，他说了这样一段话：
The Rust developers have been trying to avoid scaring kernel maintainers, and have been saying that "all you need is to learn a little Rust". But a little Rust is not enough to understand filesystem abstractions, which have to deal with that subsystem's complex locking rules. There is a need for documentation and tutorials on how to write filesystem code in idiomatic Rust. He said that he has a lot to learn; he is willing to do that, but needs help on what to learn.
（Rust 开发者一直在试图避免吓到内核维护者，他们一直在说"你只需要学一点 Rust"。但一点 Rust 不足以理解文件系统抽象，那需要处理子系统复杂的锁规则。需要有文档和教程来讲解如何用 Rust 惯用法写文件系统代码。他说他有很多要学的；他愿意学，但需要帮助来知道学什么。）
注意这句话的转变：从"你不可能逼我学"到"我愿意学，但你得告诉我学什么"。这是一个重要的信号。
Linus 的回应很实用主义：
Nobody understands the memory-management subsystem, but everybody is able to work with it.
（没人完全理解内存管理子系统，但每个人都能和它协作。）
不需要成为 Rust 专家，只需要能审查——就像你不需要完全理解某个 C 子系统的所有细节，也能审查相关的补丁。
3.4 第四幕：Wedson 的离开与 DMA 之战
2024 年 1 月，Wedson Almeida Filho 在邮件列表上提交了文件系统抽象的 RFC（[RFC PATCH 01/19] rust: fs: add registration/unregistration of file systems），然后悄然离开了项目。
他不是闹情绪走的——他只是在 Google 有了新的工作职责，无法继续投入同等精力。但 timing 实在太糟糕了。Rust-for-Linux 的核心功能还没完成，最了解内核的 Rust 开发者却走了。
Maintainers Summit 上，Miguel Ojeda 承认：
The strongest kernel expertise in the group had been Wedson Almeida Filho, who had recently left the project. That was a real loss.
（团队中内核经验最强的是 Wedson Almeida Filho，他最近离开了项目。那是一个真正的损失。）
Ojeda 说团队现在有六到七个人，大多数是"真正的 Rust 专家"，但在内核经验方面不如 Wedson。
但项目没有因此停滞。2024 年 9 月的 Maintainers Summit 上，Ojeda 向社区报告了进展，并明确提出了一个请求：需要子系统维护者的灵活性（flexibility）来配合 Rust 代码的合入。Linus 当场给出了"steam right ahead"的绿灯——但现实远比口号复杂。Binder 的 Rust 版本在 2024 年下半年持续推进，最终在 Linux 6.18 合入主线。但这条路不是一帆风顺的——每一步都需要说服对应的子系统维护者，而这些维护者中的大多数从未接触过 Rust。
然后 DMA 之战爆发了。
Rust 驱动要能用，必须能做 DMA。而 DMA 映射层是内核中最复杂、最平台相关的子系统之一——每个架构的实现都不同，涉及缓存一致性（cache coherency）、IOMMU 编程、页驻留保证（page residency）、设备寻址限制等等。一个驱动在 x86 上工作的 DMA 代码，到了 ARM 上可能就翻车。
Danilo Krummrich（Nova 驱动的作者，正在用 Rust 写 NVIDIA GPU 的开源驱动）和 Abdiel Janulgue 一起推动了 DMA 抽象层的补丁。Abdiel 是实际的补丁提交者，Danilo 提供架构指导和维护者背书。这个补丁已经迭代了多轮——从 v8 到 v15，跨越了 2025 年整个春天。Christoph Hellwig 是 DMA 映射领域的核心开发者，他的回应不是技术性的质疑，而是直接的拒绝：
Keep the wrappers in your code instead of making life painful for others.
（把封装放到你自己的代码里，别给别人添堵。）
Danilo 的回应体现了 Rust 阵营的核心立场：
Rust drivers shouldn't use C APIs directly, but rather use an abstraction of the corresponding C API.
（Rust 驱动不应该直接调用 C API，而应该使用对应 C API 的抽象层。）
Danilo 进一步解释——你可以把 Rust 抽象层想象成"一个单个的驱动在调用 DMA API"，从 C 维护者的角度，它和现有的 DMA 消费者（比如 videobuf2-dma-*）没有本质区别。
但 Hellwig 的立场没变。他给出了一个更根本的反对理由：
Interfaces to the DMA API should stay in readable C code and not in weird bindings so that it remains greppable and maintainable.
（DMA API 的接口应该保持在可读的 C 代码中，而不是奇怪的绑定中，以便保持可搜索性和可维护性。）
这场冲突迅速从技术讨论升级为社区政治事件。Hector Martin（Asahi Linux 的创始人，一个把 Linux 移植到 Apple M1/M2 的硬核逆向工程师）在社交媒体上公开批评了 Hellwig 的态度，引发了一场关于"社区影响力"的邮件列表讨论，标题是 On community influencing。
Hector 的问题很直接：如果技术论据不被接受，你在社区里还能怎么做？Danilo 的回应很务实：
Most importantly be consistent with good technical arguments, calmly focus on your actual matter...
（最重要的是用好的技术论据保持一致性，冷静地聚焦于你的实际问题……）
最终，DMA 抽象的方案绕开了 Hellwig 的直接反对——Danilo 和 Abdiel Janulgue（DMA 抽象的实际作者）提出了一个分层方案，将 Rust 绑定作为独立组件维护，不影响 C 侧的代码。Robin Murphy（DMA 映射层的 reviewer）给出了认可：
Indeed, FWIW it seems like the appropriate level of abstraction to me, judging by the other wrappers living in rust/kernel...
（确实，从 rust/kernel 中其他封装的水平来看，我认为这是合适的抽象层次。）
到 2025 年 3 月，DMA coherent allocator 的抽象已经迭代到了 v15。经过 15 个版本的打磨和无数封邮件的讨论，Danilo 作为 Nova 驱动和 Rust DMA 绑定的正式维护者（MAINTAINERS 文件中列明），与 Abdiel Janulgue 一起将方案推向合入。Robin Murphy（DMA 映射层的正式 reviewer）给出了 Acked-by。截至 2026 年初，DMA coherent 分配器的 Rust 抽象已基本就绪，scatterlist 抽象也在 v3 迭代中。Hellwig 的反对没有被忽视——而是被绕过了：方案将 Rust 绑定作为独立组件维护，Hellwig 不需要审查 Rust 代码，Rust 侧的维护由 Danilo 团队负责。这是一个典型的"不硬碰硬"的社区策略——你不让步，我就绕路走，但最终目标不变。
3.5 第五幕：实验成功
2025 年 11 月的 Maintainers Summit 上，Miguel Ojeda 做了一个总结性报告：The state of the kernel Rust experiment。
数据很明确：
- Rust 代码量在过去一年增长了 5 倍
- Android 16 系统搭载了 Rust 编写的 ashmem 模块，已经在数百万台真实设备上运行
- Debian 终于在内核构建中启用了 Rust（将在 "forky" 版本中发布）
- Nova 驱动（NVIDIA GPU 的 Rust 驱动）的部分代码已合入主线
- Rust 语言团队与内核团队建立了深度合作——Rust 编译器的 CI 中已经包含内核构建测试
- Binder 的 Rust 版本已经合入 Linux 6.18
实验被宣告为成功。
但"成功"这两个字的含义需要拆开看。Rust 在内核中仍然只占极小的比例——总共几万行代码，相对于 3000 万行 C 代码来说是沧海一粟。真正用 Rust 写的驱动只有少数几个。大多数内核维护者仍然不会 Rust。
还有一个更现实的问题：发行版支持。RHEL 等企业级发行版尚未在内核中启用 Rust。Jason Gunthorpe（RDMA 子系统维护者）在 2024 年的 Maintainers Summit 上说了一句让 Rust 阵营沮丧的话：
It will be very hard for a company to fund writing new code in Rust if none of their customers can run that code and they have to write a C version anyhow.
（如果客户的系统都不能运行 Rust 代码，公司还得写一个 C 版本，那公司怎么可能有动力投资 Rust 开发？）
这是 Rust-in-kernel 面临的最大实际障碍：不是技术可行性，而是部署现实。
用 Linus 的话说：
Getting kernel Rust up to production levels will happen, but it will take years.
（让内核 Rust 达到生产级别是会实现的，但需要数年时间。）
4. 技术拆解
这场争论的很多细节被"文化冲突"的叙事掩盖了。让我们看看几个核心的技术问题，看看反对者到底在担心什么。
4.1 编译器稳定性
Rust 内核代码目前依赖一些"未稳定"的编译器特性（nightly features）。这在 C 世界里是不可想象的——你不会让 Linux 依赖 GCC 的某个实验性扩展。
但 Rust 的情况不同。Rust-for-Linux 项目维护了一个明确的未稳定特性清单（GitHub issue #2），并且 Rust 编译器的 CI 中已经包含了内核的构建测试——这意味着如果某个编译器改动会破坏内核，它不会被合入。
Miguel Ojeda 在 2024 年澄清了版本政策：从 Linux 6.11 开始，内核需要 Rust 1.78 或更高版本的稳定版编译器。虽然仍有一些未稳定特性通过"后门"在稳定编译器中启用，但这个清单在持续缩短。
这里有一个有趣的争论。有人（比如 Red Hat 的开发者 sam_c）问：为什么内核需要依赖 Rust 的未稳定特性？这不正说明 Rust 还没准备好吗？
社区里有人回应了一个历史事实：Linux 在早年也是大量使用 GCC 的非标准扩展的。Linus 在 1991 年 comp.os.minix 的第一封邮件里就写了："It also uses every feature of gcc I could find"（它用了我能找到的 GCC 的每一个特性）。他用的是能找到的最新版 GCC——哪有什么"稳定版编译器"的概念？
但反对者也有道理：Linux 不再是一个学生项目了。它是世界上部署最广的操作系统内核。对稳定性的要求和 30 年前不可同日而语。
4.2 抽象层的哲学冲突
Rust 驱动不能直接调用 C 的函数——它需要通过"抽象层"（abstraction layer）来封装。这个封装不仅仅是语法糖，它要保证 Rust 的类型安全和内存安全约束在整个调用链上一致。
Christoph Hellwig 的反对有一部分是合理的：每个新的抽象层都意味着 C 侧的接口变更会影响 Rust 侧。谁来修？如果 Rust 开发者说"C 改了你们自己修"，C 维护者凭什么要替一个自己不熟悉的语言修代码？
但 Rust 阵营的反驳也有道理：抽象层不是 Rust 独有的需求。内核中已经有大量的 C 语言抽象层——videobuf2-dma-*、各种总线的 glue code。Rust 抽象层在技术本质上和它们没有区别。
Danilo Krummrich 说了一句很有说服力的话：
From your perspective, I think you can just think of the Rust abstraction as a single driver calling into the DMA API.
（从你的角度来看，你可以把 Rust 抽象层看作一个调用 DMA API 的单个驱动。）
换句话说：别把它当成"Rust 的东西"，就当成一个普通的 DMA 消费者。这样审查就简单了。
4.3 "你不需要学 Rust"的悖论
Rust 阵营的一个说法是：C 维护者不需要学 Rust，Rust 代码由 Rust 开发者维护。
但 Ted Ts'o 指出了这个说法的矛盾。当 Rust 代码要进入你的子系统时，"我不需要学"就不成立了。你至少需要理解这些代码在做什么，才能审查它。
Linus 的实用主义回应是：
It is not necessary to understand Rust to let it into a subsystem; after all, nobody understands the memory-management subsystem, but everybody is able to work with it.
（不需要理解 Rust 就能让它进入子系统；毕竟，没人完全理解内存管理子系统，但每个人都能和它协作。）
Arnd Bergmann（ARM 架构维护者）给出了一个更具体的观察：
Reviewing Rust abstractions for a C subsystem without knowing Rust is not difficult; he can reach a point where he understands the code, but would not feel able to change it.
（不懂 Rust 也能审查 C 子系统的 Rust 抽象；他能理解代码的意思，但不会觉得自己能修改它。）
这可能是最务实的结论：你可以审查 Rust 代码，但你不会亲自改它。Rust 代码的修改由 Rust 开发者负责。
4.4 编译器版本的鸡生蛋问题
还有一个经常被忽略的问题：Rust 编译器对各个硬件架构的支持程度。
Rust 编译器的 Tier 1 支持只有 x86-64 和 AArch64。Tier 2 加入了 AArch32、LoongArch、RISC-V、PowerPC、SPARC64。但 s390x（IBM 大型机）只有 Tier 3。
Jason Gunthorpe 的担忧很实际：如果你的客户跑的是 RHEL on s390x，Rust 驱动对他们完全没用。你还是得写 C 版本。那谁还愿意投资 Rust？
Arnd Bergmann 的观察更进一步：有 7 个架构完全没有 Rust 支持——alpha、parisc、superh、arc、microblaze、nios2、openrisc。但好消息是，这些架构要么已经是老古董，要么用户已经迁移到 RISC-V。
5. 大师点评
从这场持续 5 年的争论中，可以提炼出几条超越技术本身的规律：
技术选型从来不只是技术问题。 "Rust 比 C 更安全"是一个可以被数据支持的技术判断。但"我们应该用 Rust"是一个组织决策——它涉及培训成本、工具链迁移、权力重新分配、既有代码的兼容性。用 Linus 的话，Clang 编译内核花了 10 年——"and that was the same old language"。同一门语言尚且如此，换一门语言的阻力可想而知。
"实验"是一个政治工具，不只是技术方法。 Linus 把 Rust 标记为"实验"，既给了推进者空间，也给了反对者退路。这个标签的巧妙之处在于：它不需要在赞成和反对之间做最终选择，而是把决定推迟到了"实验结果"出现之后——而"实验结果"的定义权在谁手里，本身就是一场博弈。
变革的阻力是恒定的，不论变革是否合理。 Thomas Gleixner 把 Rust 阻力类比为 20 年前 PREEMPT_RT 遇到的阻力。历史上，内核对重大变革的接受过程从来都是恐惧→试探→接受。GNU C 支持、SMP 支持、模块化支持、设备树……每一个在当时都引发过激烈的反对。但最终，那些能证明自己价值的技术都会被接受——只是时间问题。
个人英雄主义在内核社区仍然有效，但有代价。 Wedson Almeida Filho 一个人把 Rust 推进了内核。但他离开后，项目立刻失去了最强的内核推动力。Ojeda 的团队在努力补位，但这种依赖个人的模式本身就是脆弱的。
6. 彩蛋与后续
截至 2026 年初，这场争论远未结束。几个未解决的问题：
- 发行版支持差距：RHEL 等企业级发行版仍未在内核中启用 Rust，这意味着 Rust 驱动在服务器/企业场景中暂时无法部署。Jason Gunthorpe 的鸡生蛋问题仍然无解
- 架构覆盖：Rust 目前对 x86-64 和 ARM64 的支持最好，但 RISC-V、POWER、s390x 等架构的支持仍在推进
- 第一个"真正的" Rust 驱动：Binder 已经合入（Linux 6.18），但 Nova（NVIDIA GPU 驱动）才是很多人期待的"旗舰"——它面向的用户群更广、复杂度更高
- Rust-to-C 方向：目前 Rust 代码只能调用 C 代码。什么时候 C 代码能直接调用 Rust 实现的基础设施？这将是一个重要的里程碑
- Rust BPF verifier：2025 年底有人提交了用 Rust 重写 BPF 验证器的 RFC——Alexei Starovoitov（BPF 子系统之父）的回应很直接："Just because rust is no longer experimental it doesn't mean that it's a good idea to rewrite pieces of the kernel in rust"（Rust 不再是实验性的，不代表用它重写内核模块就是个好主意）。争论还在继续
也许最有趣的一件事是：如果你回头看 2021 年 Wedson 的第一封 RFC 邮件，和 2025 年 Maintainers Summit 上"实验成功"的宣告，你会意识到——内核社区用 5 年的时间完成了对一种新语言的初步接纳。对于一个 30 岁的代码库来说，这其实已经相当快了。
《内核江湖》系列将带你走进 Linux 内核社区最激烈的争论现场——每一幕都是真人真事，每一封邮件都是历史的切面。从调度器皇位更迭到文件系统八年长征，从安全漏洞的谍战修到调度器优化的三生三世——这些故事里的技术决策，至今仍在影响你每天使用的操作系统。
7. 延伸阅读
- LWN #1006805: "Resistance to Rust abstractions for DMA mapping" — 41,667 字的完整报道，记录了 DMA 抽象冲突的全过程
- LWN #991062: "Committing to Rust in the kernel" — 2024 Maintainers Summit 报告，Linus "steam right ahead" 的出处
- LWN #1050174: "The state of the kernel Rust experiment" — 2025 年实验评估，数据总结
- LWN #953116: "A Rust implementation of Android's Binder" — Binder Rust 版详情
- LWN #910762: "A first look at Rust in the 6.1 kernel" — 首次合入的报道
- lore.kernel.org:
s:Rust DMA f:Danilo— DMA 抽象的完整邮件讨论；On community influencing线程：lore.kernel.org/linux-iommu/208e1fc3-cfc3-4a26-98c3-a48ab35bb9db@marcan.st/
下一篇预告：《内核江湖·神仙打架（二）：sched_ext——让调度器像 eBPF 一样可编程》。当 Meta 工程师 Tejun Heo 想用 BPF 重写调度策略时，传统调度器维护者们集体皱眉。从 5 次被拒到 Linux 6.12 合入——一个关于"谁来写调度器"的权力游戏。
