The end of the kernel Rust experiment

[levelworm]

https://lwn.net/Articles/1049831/

The topic of the Rust experiment was just discussed at the annual Maintainers Summit.

The consensus among the assembled developers is that Rust in the kernel is no longer experimental — it is now a core part of the kernel and is here to stay. So the "experimental" tag will be coming off.

Congratulations are in order for all of the Rust-for-Linux team.

(Stay tuned for details in our Maintainers Summit coverage.)

[bfdh]

意思是以后又得多学个 rust 了？

[levelworm]

@bfdh #1
估计会有更多的 Rust 代码吧？我不做系统开发，不知道 C 相对 Rust 这种安全一些的语言来说，还有什么比较强的优势？

[artiga033]

@bfdh 对 kernel contributor 级别的选手学个新语言又不是什么麻烦事，多的都是出于个人感情不愿意学而已

[felixcode]

标题有歧义，而且倾向于被误解为“Rust in the kernel 被终止/废弃了”

[gucheen]

@felixcode experiment ?

[YanSeven]

再探再报，那这个是不是说明 Rust 语言有了很强的“背书”了。

[felixcode]

@gucheen
Rust in the Linux kernel is no longer considered experimental.

Rust in the Linux kernel is no longer an experiment.

[PTLin]

我来科普下现在 rust 在 Linux 内核里是什么情况吧，有可能一些地方会说错。

rust for linux 对内核里的 c api 进行包装抽象，搞出 rust 形式。
但是由于内核中的 c api 抽象成 100%rust 风味的代码十分困难，所以这个项目搞了这么多年也很难说是可用，甚至其中的块设备层的抽象存在很大的问题，我还写文章进行吐槽了下 https://zhuanlan.zhihu.com/p/1945592808326013494
Asahi Linux(Macbook 上跑的 Linux 发行版)的做法是对用到的 api 抽象出 80%够自己用的，但是这种代码没办法被合并到主线，Asahi 也只能独立维护内核。

rust 的代码和 c 是一个地位，比如 panic drm qr code 功能中就会见到 drm_panic.c drm_pacic_qr.rs 在一个文件夹中，rust 代码负责计算然后导出函数供给 drm_panic.c 进行调用，但是更多的还是用于模块的编写。

至于 contributor 是完全不需要学 rust 的，因为以后的很长时间内是不会存在 Linux 中的某个功能是 rust 写的，不会 rust 看不懂的这种情况。

[skiy]

底下一堆人“标题党”。
就像说 v1.0.0beta 去除了 beta 标签一样。

[Rorysky]

@PTLin 没看明白，既然历史上 rust for linux 干抽象干的不好，怎么又合进内核了呢？ 你说的和 c 一个地位，但是不需要学 rust 什么意思？

[PTLin]

@Rorysky
“和 c 一个地位”是我没有说清楚，我想说的是以前很多人都认为 rust 只能用来写内核模块，是没有办法编写具体的系统功能，但是不是这样的，rust 也是被编译成 o 然后像是 c 一样进行链接，根据这个原理把某个 c 函数完全替换成 rust 实现是没问题，例如 drm panic qr 功能就是这么实现的。

后半句“但是不需要学 rust”的意思是，虽然 rust 理论上实现 syscall 也没问题，但是现在 rust 首先并不是强制开启的，并且想开启 rust 只能使用 LLVM 工具链，因为 gccrs 后端发展了这么多年也还是一个残废，再加上社区其实还是有极其排斥 rust 的人存在。
综上在未来的很长时间内是不会出现例如内存分配/回收这种系统核心部件的一个功能需要开启 rust 支持才能使用的这么一个情况。rust 也就只能用来写写驱动，例如 Android 上的 binder 驱动就用 rust 重写了，因为 Google 本身就在 Android 项目用到了 rust ，甚至一些核心 service 都是 rust 写的，rust 重写 binder 也就无可厚非了。

至于为什么 rust 还是被合并到主线了我的看法是。
1. 内核开发苦 c 语言久矣，c 语言由于羸弱的表达能力，原始的类型系统，导致非常容易出各种低级 bug ，例如读并发数据忘记加锁了这种情况，但是也许就是这么简单的一个 bug 最后就会被一层层精心构造出提权攻击。所以忘加锁，忘加引用计数，设计上只读的变量被不小心改了，读了一个被释放的地址等这种低级问题很容易通过 rust 解决。
2. 此外就是内核开发者年事已高，精通 c 的，精通 Linux 开发的也越来越少，需要引入新东西吸引新一代开发者。
所以在 1 的基础上引入第二语言的话几乎没有其他选择，首先就是 cpp for linux 已经被毙了很多年了，因为这玩意首先比 c 难学，其次就是黑魔法太多对 review 造成了极大困难，最后就是没办法禁用某些功能。除了 cpp 好像也就 rust 和 zig 了，zig 现在还是 unstable ，也就只能 rust 了。
3. rust for linux 的早期版本其实很有想象力，为了向世界展示出 rust 功能，抽象出了很多很多的 api ，甚至对 socket 的读写还实现了 async ，但是被正经的合并到主线之后这些都被毙了，开始进行了漫长的“完美”重写，不过这种重写也并发完全是偏执狂的自我感动，当时有很多设计确实有问题，例如因为 mutex 是原地初始化的，new_mutex 甚至是 unsafe 操作，而现在引入了 pin-init 库之后确实更加完美了。
所以综上即使现在的 rust for linux 有各种各样的问题，但是好像也只能这么搞了，希望未来这个项目能人手多一点，偏执狂少一点，该 unsafe 的就 unsafe 得了。

[levelworm]

@PTLin #11
（非你回帖的人）话说我岁数大了，作为娱乐，决定还是想办法学会用 C 写内核算了。反正内核在可见的未来，大部分代码应该还是 C 。