LWN：内核中Rust支持的下一步动作！

关注了就能看到更多这么棒的文章哦～

Next steps for Rust in the kernel

By Jonathan Corbet
September 19, 2022
Maintainers Summit
DeepL assisted translation
https://lwn.net/Articles/908347/

Rust for Linux 这个项目是希望今后可以使用 Rust 编程语言来编写内核代码，该项目已经进行了几年，有越来越多的开发者认为是时候将这项工作合并到 mainline 中了。在 2022 年的 Linux 内核维护者峰会上，Miguel Ojeda 向大家更新了此项目的最新状况，希望能达成一致来确定何时可以完成 merge。他得到的答案是很清晰的：内核中确实很快会有 Rust 了。

这方面并没有什么悬念；Linus Torvalds 在会议开始时就说，他计划接受 6.1 内核的 Rust patch（可能在 12 月中旬发布），除非他听到强烈的反对意见。Ojeda 表示，他很期待这一天，并询问这些 patch 应该如何进入 mainline。Torvalds 说，他不愿意直接接受这些 patch，所以看起来很可能需要 Kees Cook 来将这项工作引向 upstream。

Dave Airlie 说，有一些 MacBook 驱动程序的开发者打算用 Rust 来做他们的工作，所以很可能在不久之后就会有真正的 Rust 驱动程序进入 upstream 了。不过，Torvalds 说他希望最开始只合入尽量少的内容，只是让基础设施先进入内核，让开发者开始使用它。它应该可以完成编译，但应该基本仅限在 "hello, world" 这种水平就好。他说，这将是一个向世界发出的信号："终于落地了"。

Greg Kroah-Hartman 问道，针对特定子系统的 Rust binding 实现，该如何进入 upstream；是应该通过 Rust tree 还是通过相关子系统的维护者？Ojeda 回答说，core Rust 支持应该通过 Rust tree 来合入，但其他的应该经过维护者来合入。Alexei Starovoitov 担心，如果子系统维护者不想在他们的子系统中使用 Rust，他们也无法拒绝 Rust patch；James Bottomley 补充说，对于长期从事 C 语言开发的人来说，Rust 可能是一种很难理解的语言，把它强加给维护者并不合适。Torvalds 回答说，这应该由维护者决定；目前没有必要制定统一的规则。

Paolo Bonzini 说，对于不熟悉该语言的开发者来说，针对特定子系统实现抽象层的 Rust 代码往往是最难读懂的，"but it's stupid code"，并没有做什么复杂的动作。驱动程序级的 Rust 代码则要简单易懂得多。Torvalds 重申，就目前而言，维护者将可以说他们不想接受 Rust。但 Starovoitov 反驳说，无论他如何决定，BPF 都会受到影响；开发者需要能够对 Rust 代码进行 tracing 来调试问题。他补充说，每个人最终都会需要了解 Rust。Torvalds 回答说，他预计这个过程需要几年时间。

Cook 说，这种变化将类似于内核所经历的许多 C 语言变动。停止使用可变长度数组（variable-length array）也是一个类似的过程，开发人员目前已经习惯了这一点。Torvalds 说，这其实更加类似于 BPF 的引入过程；这也是一种新的语言，起初是针对特定使用场景的，但现在已经无处不在了。

Ted Ts'o 指出，内核必须使用 unstable Rust features，这就导致不好确定应该使用 Rust 的哪个版本了。也许开发者应该宣布一个特定版本的编译器作为内核开发所使用的版本？这将鼓励发行版提供商把这个版本打包发行出来，使其得以更广泛地被采用。Thomas Gleixner 说，在 kernel.org 上提供我们选定的编译器应该就够了，但 Torvalds 回答说，只要有可能，他都希望优先从发行版提供商那里获取编译器。Bottomley 问道，Rust 什么时候会成为内核编译的必备条件；答案是 "当某人需要使用的硬件需要 Rust 的时候"。Torvalds 说，如果这一天到来了，那说明 Rust 在内核开发领域是非常成功的了。

Gleixner 问 Rust 语言现在的规范性如何；Ojeda 回答说，这取决于人们希望用什么。Rust 保证了稳定功能都可以向后兼容，所以这些功能不会意外就不能用了。不过，内核正在使用一些不稳定的功能；这些功能出现变动是很有可能的。目前正在做的工作就是把这些功能稳定下来，以便让内核能够稳定地使用它们。

目前正在努力为 Rust 编写一个强调安全的系统的规范（a specification for Rust for safety-critical systems），这会最终得到一个类似于标准的文档（standard-like document）。不过 Ojeda 说目前基于 GCC 的 gccrs Rust 编译器的开发者发现当前的文档有些地方比较模糊。其中经常把相关行为定义为 "参考 rustc 编译器的实现方式"。他说，这 "不是好事"，但会继续改善。

Gleixner 还询问了生成 Rust binding 的工具，尤其是有没有自动化工具来确保 Rust 和 C 版本的数据结构是相互匹配的。Ojeda 说，这些工具确实存在，但它们还不能成功地对所有类型完成自动转换。这也是可以解决的。

最后，Gleixner 告诫 Rust 开发者不要改变 C 语言中 locking primitives 的语义；目前看来大家也没有表现出这样的倾向。Ts'o 补充说，应该从一开始就让 Rust 的 locking 抽象能跟 lockdep 这个 locking 检查工具配合起来。Chris Mason 插话说，如果 Rust 代码需要 lockdep，这将是该语言成功的另一个标志，是时候 "跳个舞庆祝胜利" 了。

人们经常说，将 Rust 合并到内核代码树中还是一个实验性质的动作；如果不成功就可以删除掉。Ojeda 说，为 Rust for Linux 工作的开发者们想知道试验期可能会有多长。不过，他并没有从这个小组讨论中得到切实的答案。

相反，Bottomley 建议说，与其引入 Rust，不如直接将更多类似 Rust 的功能移入 C 语言。Ojeda 说，他实际上一直在与 C 语言委员会合作来推动这些改进，但这方面的任何变动如果能够落实，也是需要很长的时间。Christoph Hellwig 说，除非计划用 Rust 重写整个内核，否则这种改动无论如何都得去做；他对使用一种新的语言来重写已经能正常工作的代码的方案不是很满意。他说，也许 sparse 静态分析工具可以加强一下，从而实现更多 Rust 可以做到的检查。Ojeda 回答说，这种做法最终的效果就像是又获得了一个 Rust 一样——但时间上要晚很多。

Hellwig 继续说，可以随着时间的推移，来逐步采用类似 Rust 的一些功能。这 "必定是不如从 Rust 开始"，但内核社区现在有一个庞大的代码库需要管理。他说，需要有一种方法将类似 Rust 的语言的好处纳入所有的 C 代码中。Cook 说他一直在推动编译器开发人员来创建更安全的 C 语言。

Ts'o 在会议结束时指出，语言设计本身就是一个耗时很长的研究项目；也许我们大家应该在下一年来专注于 policy 问题。Torvalds 说，他希望看到各位维护者能运行一些持续集成测试并且加入 Rust 相关的测试——这个情况其实已经在进行中了。Laurent Pinchart 说，Rust 开发者需要准备好前期需要给内核社区提供支持；开发者会很快掌握一些技能，在一段时间后应该可以开始相互帮助了。Torvalds 补充说，Rust 其实并不是那么可怕的；"毕竟不是 Perl"。

当被问及文档问题时，Ojeda 说，Rust 的开发者正试图改进一些相应的 C 语言中已经完成了的文档。例如，可以让 Rust 的文档机制能很简单地就确保这些例子是可以被实际测试通过的。他们正在完善一些规则来讲述 unsafe block 这些不安全代码块。

时间不够了，Matthew Wilcox 最后问道，内核开发人员是否应该编写 idiomatic （地道的） Rust code，还是说应该写 "C in Rust"。Ojeda 回答说，这些代码在开始时可能更像 C 语言；采用更高级的功能（如 async）可能会需要更长时间。Gleixner 问，怎样才能防止开发者使用那些不稳定的特性（是说等内核使用的特性已经变成 stable 特性之后）；答案是指定内核开发时使用的编译器版本。

全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。

欢迎分享、转载及基于现有协议再创作～

长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～