@
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 得了。