2025 年 12 月 13 日，Linux 内核开发史上一个标志性时刻：Rust for Linux 项目负责人 Miguel Ojeda 提交补丁，正式移除内核文档中关于 Rust 支持的 "实验性" 标签。这一补丁宣告了为期数年的 Rust 实验正式结束，Rust 作为 Linux 内核开发语言的地位从 "实验" 转变为 "永久采纳"。这一决定在 2025 年 Linux 内核维护者峰会上获得共识，标志着系统编程语言生态的重大转变。
从实验到正式采纳：技术、流程与社交的三重考验
Rust 支持最初在 Linux v6.1 中合并，其明确目标就是帮助内核社区评估 Rust 作为内核开发语言是否 "值得权衡"—— 这里的权衡涵盖技术可行性、开发流程适应性以及社区社交动态三个维度。正如 Ojeda 在补丁中所言："Rust 支持被合并到主线，是为了帮助确定 Rust 作为语言是否适合内核，即在技术、流程和社交层面是否值得权衡。"
如今，这一评估有了明确答案。实验结束并不意味着所有问题都已解决，而是确认了 Rust 在内核中的可行性。事实上，Rust 代码早已进入生产环境：一些知名 Linux 发行版默认启用 Rust 支持，通过 Android 系统，Rust 内核代码已经部署到数百万台设备上。这种渐进式采纳策略 —— 先实验，后生产 —— 体现了 Linux 社区一贯的务实作风。
ABI 兼容性：C 内核 API 与 Rust 所有权模型的桥接挑战
Rust 在内核集成中面临的核心工程挑战之一是 ABI（应用程序二进制接口）兼容性。Linux 内核的 C API 设计遵循特定的内存管理和调用约定，而 Rust 的所有权模型、借用检查器和生命周期系统建立在完全不同的抽象基础上。这种差异不是简单的语法转换，而是编程范式的根本不同。
类型系统桥接是首要难题。内核 C 代码大量使用void*指针、灵活数组成员和复杂类型转换，这些在 Rust 的严格类型系统中需要精心包装。Rust for Linux 项目开发了bindgen工具的定制版本，能够自动生成 C 头文件的 Rust 绑定，但自动生成的代码往往需要手动调整以确保内存安全。
内存所有权映射更为复杂。C 内核代码中，内存管理通常通过引用计数（kref）、自旋锁或 RCU 机制实现。Rust 的所有权系统需要将这些机制映射到Arc、Mutex或自定义的Rc类型。然而，内核特有的内存分配器（kmalloc、vmalloc）和释放策略需要特殊的 Rust trait 实现，确保 Rust 的Drop trait 与内核的释放函数正确对接。
调用约定对齐涉及底层细节。内核与用户空间的系统调用、中断处理程序、软中断等都有特定的栈布局和寄存器使用约定。Rust 代码必须生成完全兼容的机器码，这要求编译器后端（LLVM）与内核构建系统的深度集成。目前，混合 GCC+LLVM 构建仍处于实验阶段，GCC 的 Rust 前端支持也在开发中，这是未来需要攻克的技术堡垒。
内存安全保证：实证数据与性能权衡
USENIX ATC 2024 的一篇实证研究论文《An Empirical Study of Rust-for-Linux: The Success, Dissatisfaction, and Compromise》提供了量化数据，揭示了 Rust 在内核中的实际效果。研究分析了 6 个关键的 RFL 驱动，涉及数百个问题、PR、数千个 GitHub 提交以及超过 12,000 条 Zulip 讨论。
漏洞减少效果显著。研究显示，将 C 模块重写为 Rust 后，内存安全漏洞数量从约 10 个减少到 0 个。这种减少不是偶然的 ——Rust 的编译时检查确实能够消除整类漏洞：缓冲区溢出、使用后释放、数据竞争等。对于内核这种对可靠性要求极高的环境，这种安全提升具有革命性意义。
性能开销可控。安全提升的代价是性能开销，但数据显示这一开销相当有限。对于非封装的 Rust OOM（内存不足）处理程序端口，性能开销约为 0.7%；对于完全封装的变体，开销最高达到 3%。考虑到安全性的巨大提升，这一性能代价在许多场景下是可以接受的。更重要的是，随着编译器优化和惯用 Rust 代码的积累，这一开销有望进一步降低。
开发成本增加。研究也指出了 Rust 开发的 "不满意" 之处：开发人员需要投入更多精力处理所有权和生命周期问题。内核开发中常见的模式 —— 如环形缓冲区、复杂锁策略、DMA 映射 —— 在 Rust 中需要更精细的设计。但这种 "开发成本" 实际上是将运行时错误转移到了编译时，从系统可靠性角度看是值得的投资。
工程实现细节：安全抽象与不安全边界的划定
Rust for Linux 项目的核心工程成就是建立了一套安全抽象层，将不安全的内核操作封装在安全的 Rust 接口之后。这一设计遵循 "最小化不安全代码" 原则：只有直接与 C API 交互的边界层使用unsafe块，内部实现尽可能保持安全。
kernel crate 设计。项目创建了专门的kernel crate，提供内核特有的类型和 trait。例如：
CStr和CString用于与 C 字符串互操作Result<T, Error>映射到内核错误码Box、Vec等标准库类型被重新实现以使用内核分配器Mutex、SpinLock等同步原语提供与内核对应的 RAII 包装
不安全边界的明确划分。每个驱动程序都明确定义了哪些函数是unsafe的，通常是与硬件直接交互或执行内存映射的操作。通过将不安全代码集中到少数几个函数中，大部分驱动程序代码可以保持安全，享受 Rust 的所有权保证。
生命周期注解的实践。内核代码中常见的模式 —— 如设备注册后保持引用、中断处理程序的生命周期管理 —— 都需要精确的生命周期注解。Rust for Linux 项目积累了丰富的模式库，帮助开发者正确标注这些关系，避免常见的生命周期错误。
未来挑战：工具链、架构支持与生态系统建设
尽管实验结束，Rust 在内核中的旅程才刚刚开始。Ojeda 在补丁中明确指出："这并不意味着所有内核配置、架构、工具链等都能正常工作，也不意味着不会有新问题出现。在所有领域，从内核到上游 Rust、GCC 和其他项目，仍有大量工作要做。"
工具链碎片化是当前主要挑战。Linux 内核传统上使用 GCC 编译，而 Rust 默认使用 LLVM 后端。混合构建（部分 C 代码用 GCC，Rust 代码用 LLVM）仍处于实验阶段。GCC 的 Rust 前端（gccrs）正在开发中，但要达到生产就绪状态还需要时间。这种工具链分裂增加了构建复杂性，也影响了跨架构支持。
架构支持不完整。目前 Rust 支持主要集中在 x86_64 和 ARM64 架构。对于 MIPS、PowerPC、RISC-V 等其他架构，支持程度不一。内核的特定架构代码（如页表操作、中断控制器）需要相应的 Rust 绑定，这是一项长期工程。
生态系统建设。Rust 在内核中的成功不仅取决于语言本身，还取决于工具链、文档、培训材料和社区支持。需要更多开发者熟悉 Rust 和内核开发的双重技能，需要更多公司投资于开发者培训，需要更完善的调试和分析工具链。
向后兼容性维护。随着内核演进，C API 会发生变化。Rust 绑定需要同步更新，同时保持现有驱动程序的兼容性。这要求 Rust for Linux 项目建立稳定的 ABI 保证策略，或者提供版本化的绑定接口。
可落地的工程建议
对于考虑采用 Rust 进行内核开发的组织和开发者，以下建议基于当前实践经验：
-
渐进式采纳策略：从非关键模块开始，如辅助驱动程序、文件系统插件或网络协议扩展。避免一开始就重写核心子系统。
-
投资工具链建设：建立本地化的构建和测试环境，包含定制的
bindgen配置、交叉编译工具链和自动化测试框架。 -
明确安全边界：在项目开始时就划定
unsafe代码的范围，建立代码审查流程专门检查不安全代码的正确性。 -
性能基准测试：为 Rust 模块建立详细的性能基准，与对应的 C 实现对比，监控内存使用、CPU 利用率和延迟指标。
-
参与上游贡献：将本地改进贡献回 Rust for Linux 项目，帮助完善
kernelcrate 和基础设施，从社区反馈中学习最佳实践。 -
培训与知识转移：为 C 内核开发者提供 Rust 培训，重点关注所有权模型、生命周期和与 C 互操作的模式。
结语：系统编程的新篇章
Rust 实验的结束标志着系统编程进入新阶段。这不仅是 Linux 内核的技术演进，更是整个软件行业对内存安全重视程度的体现。正如美国 ONCD 报告所指出的，内存不安全语言是网络攻击的主要原因，而 Rust 的保证对于安全关键基础设施至关重要。
从工程角度看，Rust 在内核中的成功证明了现代类型系统与传统系统编程可以和谐共存。ABI 兼容性挑战虽然艰巨，但通过精心设计的抽象层和明确的边界划分是可以克服的。内存安全的提升虽然带来一定的开发成本，但从系统可靠性和安全性角度看，这种投资是值得的。
未来几年，我们将看到更多 Rust 内核代码进入生产环境，更多架构获得完整支持，更多开发者掌握这一双重技能。Linux 内核作为开源世界的基石，再次引领了技术创新的方向。Rust 的实验结束了，但 Rust 在内核中的故事，才刚刚开始。
资料来源：
- LWN.net 文章 "rust: conclude the Rust experiment" (2025-12-13)
- USENIX ATC 2024 论文 "An Empirical Study of Rust-for-Linux: The Success, Dissatisfaction, and Compromise"