从实验到生产：Rust 正式成为 Linux 内核的“一等公民”

　　Rust 进入 Linux 内核并非一蹴而就。

　　Linux 6.1 (2022年) ：Linus Torvalds 首次允许 Rust 基础设施代码合并入主线。当时，它更像是一个“概念验证”，几乎没有实际功能的驱动程序。

　　Linux 6.2 - 6.11 ：这是“打地基”的两年。开发者并未急于重写大驱动，而是专注于构建 Box 、 Arc 、 Workqueue 和锁机制的 Rust 抽象。没有这些，写驱动就像在用裸机代码。

　　Linux 6.13+ (现在) ：随着抽象层的成熟和关键驱动（如 Asahi GPU、Android Binder）的推进，社区达成了共识——Rust 可以在生产环境中运行了。

　　移除“实验性”标签的直接后果是： 红帽 (Red Hat)、Ubuntu、SUSE 等下游发行版，现在有了充分的理由在默认内核中开启 Rust 支持，而无需担心 API 随时崩溃。

　　在 Hacker News 的讨论中，争议最激烈的并非技术细节，而是 “责任归属” 。

　　在 Linux 内核开发中，有一条铁律： “如果你修改了内核 API，你必须修复所有因此破坏的调用（You break it, you fix it）。”

　　在实验阶段 ：Rust 享有一种特权。如果 C 语言的维护者修改了核心 API 导致 Rust 代码编译失败，他们可以置之不理，留给 Rust 团队事后修复。

　　在正式阶段 ：Rust 失去了“豁免权”。理论上，任何修改内核核心的 C 开发者，都有义务确保他们的修改不会破坏现有的 Rust 驱动。

　　这引发了深层的担忧： 那些不懂 Rust 的资深 C 维护者，是否会被迫去学习 Rust？

　　目前的社区共识倾向于一种务实的“混合双打”模式：虽然规则如此，但在实际操作中，Rust 团队仍将承担主要的适配工作。但这标志着 Rust 代码不再是“二等公民”，它有了要求 C 开发者协作的“政治地位”。

　　尽管 Rust 承诺了内存安全，但将其嫁接到拥有 30 年历史的 C 代码库上，依然面临严重的 “阻抗匹配（Impedance Mismatch）” 问题。

　　Linux 以“能在任何东西上运行”著称，支持从超算到路由器的海量架构。相比之下，Rust 的 Tier 1/2 支持列表要小得多。 这带来了一个尴尬的问题：如果一个核心功能用 Rust 重写了，那些 Rust 编译器不支持的古老架构（如某些旧的嵌入式 CPU）怎么办？目前的答案是：Rust 主要用于 驱动程序 （Drivers），而非核心内核（Core Kernel），因此不支持 Rust 的架构均可选择不编译相关驱动。

　　Linux 内核充满了 C 语言特有的黑魔法，例如：

　　位域（Bitfields） ：在 C 中定义硬件寄存器非常直观，而在 Rust 中则需要宏或特定的 crate 支持，显得笨重。

　　侵入式数据结构（Intrusive Data Structures） ：内核常用的链表设计与 Rust 的所有权模型天生冲突，通过 unsafe 和 Pin 来模拟这些结构极其痛苦。

　　抛开争议，Rust 已经在内核的关键领域扎下了根：

　　高复杂度驱动 ： Asahi Linux 的 Apple Silicon GPU 驱动完全使用 Rust 编写。它证明了 Rust 可以处理极度复杂的并发和硬件交互，这是最有力的技术背书。

　　移动端的刚需 ：Google 正在推动用 Rust 重写 Android 的 Binder IPC 机制。这不再是社区的兴趣，而是商业公司消灭内存安全漏洞的刚需。

　　用户可见的功能 ：Arch Linux 和 NixOS 用户可能已经见过 Rust Panic Screen ——当内核崩溃时，屏幕上会显示一个二维码，这也是 Rust 编写的。

　　移除“实验性”标签，并不意味着 Rust 会一夜之间取代 C。

　　我们将进入一个长期的 共存时代 ：C 语言继续守护调度器、内存管理等核心底层，发挥其极致的灵活性；而 Rust 则在驱动程序、文件系统和网络协议栈等“高危”外围区域，提供急需的内存安全保障。

　　对于系统开发者而言，这或许是一个信号： 你不需要立刻成为 Rust 专家，但在 2025 年，能够读懂 Rust 代码，可能已成为内核开发的必备技能。