Rust 进 Linux 内核两年:新驱动涌现、社区争议不断,这场实验还在继续

Rust 进入 Linux 内核已经两年了。这场"系统编程语言革命"进展如何？

答案是：比悲观者预期的要好，比乐观者想象的要难。

根据内核社区的公开数据，截至 2026 年初，已有数十个驱动和模块使用 Rust 编写。虽然在整个内核代码量中占比仍然很小，但考虑到 Linux 内核有超过 3000 万行代码，两年内从零增长到这个水平，已经是相当可观的进展。

但与此同时，Rust for Linux 项目也经历了多次风波。核心开发者离职、维护工作暂停、邮件列表爆发激烈辩论——这些事件折射出一个新技术融入复杂系统时的真实阵痛。

两年时间，Rust 在 Linux 内核中既没有"改变一切"，也没有"无疾而终"。它正在经历一个缓慢、曲折、但确实在前进的过程。

数据说话：Rust 在内核中的实际落地

驱动和模块数量

Rust 在内核中的应用主要集中在以下几个领域：

• 字符设备驱动：包括一些核心设备和测试框架
• 网络驱动：主要是虚拟网络设备
• 平台驱动：ARM 平台相关驱动
• 文件系统：简单的测试文件系统
• 其他模块：包括内核测试框架、示例代码等

这些驱动大多是新写的，而不是从 C 重写。这说明内核社区对 Rust 的态度是"新代码可以尝试用 Rust，但老代码没必要重写"——一个务实的选择。

性能对比：Rust 驱动 vs C 驱动

关于 Rust 和 C 驱动的性能对比，业内有一些非正式的测试和研究。总体来看：

• 运行时性能：Rust 和 C 基本持平，差异通常在 5% 以内
• 代码量：Rust 代码通常比等效的 C 代码少 10-20%，得益于更高级的抽象
• 编译后大小：Rust 二进制可能略大，但差距不大
• 静态分析警告：Rust 代码的静态分析警告明显少于 C 代码

这些测试的结论是一致的：Rust 的内存安全特性在编译期消除了大量潜在 bug，而运行时性能几乎没有损失。

安全漏洞统计

这是 Rust 最被寄予厚望的领域：内存安全漏洞。Linux 内核历史上最严重的安全问题，绝大多数都是内存相关的——缓冲区溢出、空指针解引用、Use-After-Free 等。

从理论上看，Rust 的所有权系统和借用检查器应该在编译期阻止这些问题的发生。实际效果如何？

目前 Rust 代码在内核中的占比仍然很小，样本量不足以得出"Rust 彻底解决内存安全问题"的结论。但从 Google 在 Android 内核中使用 Rust 的经验来看，Rust 代码的内存安全漏洞确实显著少于等效的 C 代码。

这个结论符合预期：Rust 的内存安全承诺在内核场景下是经得起检验的，但前提是正确使用 unsafe 块。

文化冲突：C 老兵 vs Rust 新生代

Rust 进内核，最大的阻力不是技术，而是人。

社区争议

Rust 进内核的过程并非一帆风顺。项目经历了几次核心开发者离职和暂停维护的风波。这些事件背后，反映了新旧两派开发者之间的理念冲突。

核心争议点包括：

1. Rust 代码是否需要遵循 C 代码的所有惯例？ Rust 开发者认为某些 C 惯例在 Rust 中没有意义，C 维护者坚持"内核风格必须统一"。
2. unsafe 代码块的处理方式？ Rust 的 unsafe 关键字标记"绕过编译器检查的代码"，C 开发者认为这增加了复杂度。
3. 文档和注释风格？ C 代码使用 kernel-doc 格式，Rust 有自己的文档系统，两者如何统一？

Linus Torvalds 的态度一直是关键。他多次公开表态：**"Rust 是内核的一部分，但不是要取代 C。两种语言可以共存，各自发挥优势。"**

代际差异

Rust 开发者和 C 开发者之间存在明显的代际差异：

这种差异不是对错之分，而是不同时代的工程师文化。C 开发者经历过太多"新语言最后都死了"的情况，对 Rust 的态度自然更保守。Rust 开发者则认为现代语言设计已经进步了很多，不应该用老眼光看待。

现实检验：Rust 的内存安全承诺兑现了吗？

Rust 的核心卖点是"内存安全"，但这个承诺在内核场景下是否真的成立？答案比"是"或"否"更复杂。

unsafe 的现实

在用户态程序中，Rust 代码大部分是"safe"的——编译器保证内存安全。但在内核中，情况不同。

根据 Rust for Linux 项目的统计，内核中的 Rust 代码约 15-20% 使用了 unsafe 块。这个比例远高于普通用户态程序（通常 < 5%）。

为什么内核 Rust 代码需要这么多 unsafe？主要原因：

1. 直接操作硬件：内核需要直接读写内存地址、操作寄存器，这些操作本质上是不安全的
2. 与 C 代码交互：调用 C 函数时，Rust 无法验证 C 代码的安全性
3. 性能优化：某些场景下，绕过编译器检查可以获得更好的性能

这意味着：**Rust 在内核中并没有完全消除内存安全问题，而是把问题从"到处都可能有 bug"缩小到"只在 unsafe 块中可能有 bug"**。

实际发现的 bug

尽管有 unsafe 块，Rust 代码的 bug 数量仍然明显少于 C 代码。根据 Google 在 Android 项目中公开的数据，他们使用 Rust 编写的驱动，bug 密度显著低于 C 驱动。

更重要的是，当 bug 发生时，Rust 的类型系统往往能将影响范围限制在更小的模块内，而不是像 C 那样可能导致整个系统崩溃。

给系统开发者的三点建议

无论你是 Rust 支持者还是怀疑者，Rust 进内核已经是一个不可逆的趋势。以下是我的三点建议。

1. 学习 Rust，但不要急于在生产中替换 C

如果你是内核开发者或嵌入式开发者，学习 Rust 是有价值的。它代表了一种新的系统编程范式，即使你不打算用它写内核，也能从中学到很多关于内存安全和并发编程的知识。

但不要急于在生产环境中用 Rust 替换现有的 C 代码。Rust 最适合的场景是新项目、新模块，而不是重写旧代码。重写的风险包括：

• 引入新 bug（新语言 + 新代码 = 双重风险）
• 破坏与现有 C 代码的兼容性
• 团队学习曲线导致的效率下降

2. 关注 Rust 生态的工具链成熟度

Rust 进内核的一个重要挑战是工具链。C 语言有 40 多年的工具积累（gcc、llvm、gdb、valgrind 等），而 Rust 的内核开发工具还处于早期阶段。

目前，Rust 内核开发面临以下工具问题：

• 调试支持不完善：gdb 对 Rust 的支持不如对 C 的支持完善
• 性能分析工具缺失：perf、ftrace 等工具对 Rust 的支持有限
• 静态分析覆盖不足：现有的内核静态分析工具主要针对 C 代码

如果你打算用 Rust 写内核代码，需要准备好应对这些工具链的不足。

3. 参与 Rust for Linux 社区

如果你对 Rust 和内核开发都感兴趣，Rust for Linux 社区是一个很好的切入点。项目目前最需要的是：

• 驱动移植：选择一个简单的驱动，用 Rust 重写
• 工具链改进：改进调试器、性能分析工具对 Rust 的支持
• 文档编写：帮助完善 Rust 内核开发的文档和教程

参与这个项目，既能学习前沿技术，又能为开源社区做贡献。

最后

Rust 进 Linux 内核两年，给我的最大感受是：技术变革是一个缓慢的过程，尤其是在系统级软件中。

两年时间，数十个驱动，占比仍然很小——这些数字看起来微不足道。但如果把时间尺度拉长到 10 年呢？2016 年，Rust 还是一个只有几千用户的小众语言；2026 年，它已经成为 Linux 内核的官方支持语言。

C 语言统治系统编程 50 年，不是因为它完美，而是因为它"够用"。Rust 想要取代 C，不需要证明自己"完美"，只需要证明自己在某些场景下"更好用"。

这个证明过程正在进行中。Rust 在内核中的旅程才刚刚开始。而且 AI 会加速这个过程，AI 让 Rust 更流行了！