文 |姑苏九歌

编辑 |姑苏九歌

Linux内核最近干了件大事，Rust语言折腾五年，终于从“实验品”变成正式成员了。

这事儿放五年前想都不敢想，毕竟Linux内核几十年都是C语言的“天下”。

聊起这事儿，还得从2020年说起。

当时RustforLinux项目刚启动，定位特别小心，不是来抢C语言饭碗的，就是想试试“值不值得为安全多花点功夫”。

那会儿代码上都标着“experimental”，跟个旁听生似的，就怕步子迈大了扯着内核的“老骨头”。

内核开发可不是闹着玩的，这些年Linux内核没少因为内存漏洞头疼，缓冲区溢出、空指针解引用之类的问题，隔三差五就冒出来。

Rust的内存安全模型正好能治这个，但反对的声音也不少。

有人说，引入新语言等于重构工具链，LLVM依赖、构建流程变复杂，维护起来更费劲。

争议归争议，真本事还得看实际进展。

2022年是个关键节点，超过2万行Rust代码被合入Linux上游内核，不再是小打小闹的demo，成了正经要长期维护的工程代码。

更实在的是，GooglePixel系列手机直接用上了Rust写的底层驱动，跑了这么久没出大问题，算是给“稳定性”交了份合格答卷。

如此看来，五年实验不是白折腾的。

今年LinuxkernelMaintainersSummit上，大家终于达成共识，Rust的适配性过关了，“实验”标签可以摘了。

项目负责人MiguelOjeda在邮件列表里说得明白，“再说‘实验’就不准确了，Rust以后是内核的长期成员。”

五年实验路，从“旁听生”到“正式成员”

转正归转正，麻烦事儿其实才刚开始。

最头疼的就是硬件架构适配，x86、ARM这些主流架构还好，像RISC-V这类小众架构，Rust支持还在补窟窿。

有开发者吐槽，“同一套驱动代码，在x86上跑得顺，到RISC-V上就报错，调试起来头都大了。”

工具链也是个老大难，Linux内核一直用GCC编译，Rust却依赖LLVM，现在搞混合构建，兼容性问题没少出。

虽说GCC团队在开发原生Rust支持，但啥时候能稳定用起来，谁也说不准。

搞不清的是，为啥不能早点把这事儿提上日程？

代码规范也得磨合，C语言在kernel混了几十年，规矩早就定死了，Rust是新来的，编码风格、测试流程都得跟C对齐，不然以后代码各写各的，维护起来就是灾难。

有老开发者说得实在，“不是不让用新语言，但不能搞成‘语言孤岛’，最后苦的还是咱们这些敲代码的。”

驱动落地倒是挺积极，AppleSilicon的GPU驱动项目Asahi，打算在Linux6.17里加入Devicetree支持，争取早点上游合入。

NVIDIA的Nova驱动，目标是取代老的Nouveau，计划Linux6.19完成初始启用，ARMMali的Tyr驱动更猛，Linux6.18上已经能跑GNOME桌面和基础游戏了。

这些案例说明，Rust在驱动领域确实能干活。

转正后，Rust要面对的“硬骨头”

Rust的安全价值，不光内核能用。

Firefox浏览器、Cloudflare的边缘服务，早就靠Rust提升安全了。

说起来，这事儿也影响了C语言社区，现在他们也在加强静态分析工具研发，算是互相促进吧。

回顾历史，内核也不是没试过其他语言。

C++当年因为太复杂，没搞起来，Python性能不行，只能写写脚本。

Rust能成，关键是平衡得好，安全上比C强，性能又没掉链子，这才让内核社区松了口。

现在内核社区在琢磨C和Rust怎么好好相处，比如FFI接口怎么设计，内存管理怎么协同。

这种“协作而非取代”的模式，怕是未来的主流。

毕竟C语言几十年的家底摆在那儿，想彻底换掉不现实。

长远来看，Rust可能会推动内核搞点新花样。

模块化设计、实时性优化这些老大难问题，说不定能用Rust的抽象能力简化开发。

高校和企业也开始行动了，把Rust纳入内核开发课程，以后新人进来，怕是得同时懂C和Rust，“双语言思维”要成标配了。

总的来说，Rust这五年实验，就是开源项目面对新技术的典型操作，先小心试，试好了再慢慢推进。

转正不代表C语言要退休，而是多了个“安全搭档”。

随着生态越来越成熟，工具链问题解决了，硬件支持全了，Linux内核说不定真能迎来“安全和效率都在线”的新时代。