Linux 内核顶级维护者:写了 35 年 C,是 Rust 让我重新找回了编程的乐趣

在开源软件的宏大版图中，Linux 内核无疑是那座最古老、最庞大、也最不容有失的钢铁巨塔。它由数千万行 C 语言代码铸就，运行在世界上每一个数据中心、每一台智能手机，乃至公司的投影仪和麦克风里。

在这个由 C 语言统治了三十多年的“神圣领域”，任何关于引入新语言的提议，都曾被视为不可理喻的异端。

然而，巨变正在悄然发生。

在最新一期的 Rust in Production 播客中，两位行业殿堂级人物坐在一起，进行了一场载入 Linux 史册的对话，揭示了 Linux 内核史上最伟大的语言融合：

• Greg Kroah-Hartman：Linux 内核核心维护者，掌管着驱动核心（Driver Core）、USB、TTY 以及所有稳定版本（Stable Kernels）的发布，写了 35 年 C 语言的绝对骨灰级老炮。
• Alice Ryhl：Google Android Rust 团队成员，高并发异步运行时 Tokio 的维护者，将 Rust 引入 Linux 内核的主力军。

在这场深度对话中，Greg 坦言自己曾是一个坚定的“Rust 怀疑论者”，但现在，他不仅公开宣布“Linux 引入 Rust 的实验已经结束，它已经是正式项目”，更说出了一句让无数技术人动容的话：

“Rust 让我觉得，写程序重新变得有趣了。”

为什么一个掌控着世界底层算力命脉的 C 语言守护神，会被 Rust 彻底征服？在 Linux 这个极致复杂的系统级工程里，Rust 究竟带来了怎样的化学反应？

信任的重构：代码可以出错，但我们必须信任你

在 Linux 内核这样不容许任何安全妥协的底层项目中，引入一门新语言，最大的挑战是什么？

Alice 和 Greg 给出了同一个反直觉的答案：最大的挑战不是技术，而是社会学（Social Challenge）。

“内核的运转，本质上是基于对‘人’的信任。”Greg 解释道。

在 Linux 社区，每天都有几千名开发者提交补丁。资深维护者们并不指望任何人写出完美无缺的代码，因为“我们都会犯错”。

“我们信任你，不是信任你的代码不会出错；而是信任当代码出错、系统崩溃时，你会守在电脑前把它修好。”

在过去的二十年里，有很多系统编程语言（比如 C++）曾试图叩开 Linux 内核的大门，但它们的倡导者写完代码就走了，没有人愿意留下来承担那份沉重、枯燥的长期维护责任。

而 Rust 社区的先驱们用了整整 8 年时间，在内核树外（Out of tree）默默编写驱动、完善基础设施，用实际行动向 Greg 这样的内核守门人证明：“我们不仅能写出安全的代码，而且我们做好了准备，会留在这里和你们一起修 Bug。”

正是这种长期主义的务实精神，建立起了难能可贵的信任（Trust）。

奇妙的化学反应：Rust 的到来，竟然让原有的 C 代码变好了！

当 Rust 真正开始深入内核的毛细血管时，发生了一个极其奇妙、甚至带有一丝讽刺意味的现象：即使你完全不碰 Rust 代码，原本的 C 语言代码也因为 Rust 的到来而变得更好了。

Alice 分享了她们在编写绑定（Bindings）时的技术细节。在 C 语言中，一个指针的定义往往是极其模糊的：

// C 语言中的经典指针返回
struct device *get_device_info(void); 

这个指针返回后，调用者需要面对一系列拷问：

• 这个指针代表的是“所有权（Ownership）”的转移，还是仅仅是一次“借用（Borrow）”？
• 它指向的内存在生命周期结束时，是由我来释放，还是由系统释放？
• 它是可变的（Mutable）还是只读的？

在 C 语言的签名里，这些信息全部是缺失的，只能靠开发者查阅文档、或者在脑海里默默推理。

但当 Alice 试图为这段 C 代码编写 Rust 包装器（Wrapper）时，由于 Rust 编译器的强制要求，她们必须在 Rust 签名中明确定义：它是Arc，是Box，还是一个简单的引用（Reference）？

为了让 Rust 编译器满意，Rust 团队不得不去倒逼 C 语言维护者厘清这些指针的语义。

“在很多地方，写 Rust 绑定的开发者需要写几百行复杂的代码，就为了兼容某个极其难用的 C 语言接口。”Greg 笑着回忆道，“我看到后说：‘其实我们可以直接修改 C 语言代码，让它变得更简单。’ 那些写 Rust 的人惊呼：‘噢，原来还可以这样！’”

“即便 Rust 在今天突然消失，Linux 的 C 语言代码库也因为 Rust 曾经来过，而变得比以前安全、清晰、健壮得多。” 这是 Greg 给出的极高评价。这种跨语言的协同审视，正在洗礼整个 Linux 内核的工程素养。

纠正偏见：为什么写“驱动”比写“内核核心”难得多？

在很多开发者的刻板印象中，写底层的内核核心（如调度器、内存分配器）是最难的，而写外围的“驱动（Drivers）”是最简单的。

Greg 站出来彻底纠正了这个偏见：“在内核中，写驱动才是最难的。因为驱动虽然看起来是树叶，但它在疯狂地消费整棵树干的养分。”

Alice 在为 Android 编写 Rust 驱动时，深刻体会到了这一点。一个驱动为了运转，必须去调用内存分配（Alloc）、调用 I/O 模块、调用网络包分析、调用文件系统。这意味着，你要写一个 Rust 驱动，你就必须先把这所有涉及到的 C 语言核心模块，全部写出对应的 Rust 绑定。

1. 为什么不能用标准的 Rust 内存分配器？

很多人问，为什么不能直接用 Rust 标准库里的alloc？

因为 Linux 内核的内存分配（malloc）绝非易事。它不是简单的“要一块内存”，而是充满了极其细微的上下文提示（Gfp flags）：

• “在中断上下文中，不能睡眠，请立刻给我内存”；
• “不要去触发 I/O 写入，直接从那个特定的 NUMA 节点上拿内存”；
• “从这个特定的内存池（Memory Bucket）里分一块给我”。

为了满足这些变态的底层硬件级要求，Rust 用户态标准库那一套内存分配器根本无法工作。Rust for Linux 团队不得不完全剥离了std，甚至重写了适用于内核特性的定制版alloc库。

2. 极致的极客工具：Klint 与编译期“禁眠”检查

为了解决这些极其精细的内核场景，内核团队甚至编写了专属的编译器插件——Klint（Kernel Lint）。

在内核开发中，有一个铁律：在持有某些特定锁或处于中断上下文时，绝对不允许发生系统休眠（Sleep）。如果 C 程序员犯了这个错，系统往往会直接卡死、甚至死机，极难调试。

而 Klint 作为一个 Rust 编译器插件，能够利用编译期的类型系统，在编译时直接扫描整个代码路径，一旦发现你在不允许睡眠的上下文中调用了任何可能触发睡眠（Sleep）的函数，直接报编译错误！

这种在编译期就把低级内存与调度错误彻底掐灭的能力，是传统的 C 语言静态分析工具（如 Coccinelle）在不破坏代码可读性的前提下，永远无法企及的高度。

释怀：35 年 C 老炮被 Rust 治愈的瞬间

当主持人问及，C 程序员能从 Rust 身上学到什么时，Greg 的回答没有滔滔不绝的说教，反而充满了真诚与坦然。

“过去，当我写 C 语言时，如果要在两个模块间传递一个指针，我必须在脑海里进行高强度的思想斗争：这个指针是谁在持有？生命周期对不对？我有没有在别处释放它？”

“当我接触到 Rust 之后，我发现，Rust 帮我把这些繁琐、痛苦、容易出错的 meta-stuff（元认知开销）全部承担了。”

“编译器编译通过了，逻辑看起来也是对的。好了，我现在可以百分之百地把精力放在我的业务逻辑本身，而不需要去担心那些低级的内存越界和空指针问题。”

“写了 35 年的 C，Rust 让我重新觉得，编程是一件纯粹且快乐的事情。”

这或许是一个程序员，对一门新编程语言所能表达的最高敬意。

小结

在对话的最后，现场响起了经久不息的掌声。

Linux 的伟大，不在于它用了 30 多年的 C 语言，而在于它拥有一个极其开放、务实且充满活力的工程文化。当有更好的工具出现时，这些掌控着世界算力命脉的守护者们，没有抱残守缺，而是选择张开双臂，去拥抱改变。

从 Python 狂飙的 AI Agent 调度层，到 Go 统治的云原生 Agent编排底座，再到 Rust 正在接管的 Linux 内核最深处——无论上层的应用和模型如何演进，底层的系统工程（Systems Engineering）依然需要人类最顶尖的逻辑、同理心与工匠精神去雕琢。

我们有幸见证这场跨越语言与时代的融合，更有幸与这些伟大的建设者们同行。

资料链接：

• https://corrode.dev/podcast/s06e04-rust4linux/
• https://www.youtube.com/watch?v=HM-JM4DoYD4

✍️ 今日开放讨论：

Greg 提到“Rust 绑定的过程，反过来倒逼并简化了 C 语言的原生接口”。在你的项目或日常重构中，是否也曾因为引入了更严苛的约束（如类型系统或静态检查），反而帮助你理清了原本混乱的业务逻辑？

欢迎在评论区分享你的跨语言协作与架构重构故事，我们一起聊聊代码的纯粹之美！

🔥 还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏《从0 开始构建 Agent Harness》将带你：

• 抛弃臃肿框架，回归“驾驭工程 (Harness Engineering)”的第一性原理
• 用 Go 语言手写 ReAct 循环、并发拦截与上下文压缩引擎等，复刻极简OpenClaw
• 构建坚不可摧的 Safety Middleware 与飞书人工审批防线
• 在底层实现 Token 成本审计、链路追踪与自动化跑分评估
• 从“调包侠”进化为掌控大模型边界的“AI 操作系统架构师”

扫描下方二维码👇，开启从 0 开始构建Agent Harness 的实战之旅。