LWN：内核要给Rust什么地位？

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

Committing to Rust for kernel code

By Jonathan Corbet
November 22, 2023
Maintainers Summit
ChatGPT translation
https://lwn.net/Articles/952029/

在过去的几年里，Rust 一直是 Kernel Maintainers Summit 的一个突出主题，而 2023 年的会议延续了这一传统。正如 Rust-for-Linux 的开发者 Miguel Ojeda 在专门讨论这个主题的会议开始时所指出的，过去一年里，使用 Rust 进行内核开发的兴趣显著提高了。但是 Rust 也被明确是作为一个实验来添加到 Linux 内核的；内核社区现在是否准备宣布这个实验取得了成功呢？

Ojeda 表示，Rust-for-Linux 项目在过去一年里增加了一名全职工程师和一名学生开发者。各种公司也加入其中来支持这项工作。目前正在进行让Coccinelle工具与 Rust 代码一起工作的工作。目前的一个优先任务是为正在发布的代码引入更多 review 人员。

在工具链方面，基于 GCC 的 Rust 编译器gccrs的工作已经显著放缓。rustc的GCC代码生成器取得了更好的进展；它现在可以编译内核代码，并已经合并到编译器内部。这个基于 GCC 的后端将使 Rust 支持扩展开来，原来基于 LLVM 的 rustc 不支持的体系结构也可以支持了。与此同时，Rust 项目本身正在加大对这项工作的参与；这是个好消息，因为内核有一些独特的要求，并且需要保证语言的改动不会在未来破坏内核代码。

在内核中的各个子系统正在进行一些工作。Android 的 binder 的 Rust 实现运行良好，其性能与 C 实现相当。实现这一点所需的 unsafe 代码数量很少，这非常让人开心。Wedson Almeida Filho 正在进行文件系统绑定的工作，目前主要是针对只读功能进行支持。其目标是最终可以在 100%安全的 Rust 中实现文件系统。

总体而言，他发现越来越多的维护者对使用 Rust 的想法持开放态度。然而，这引出了 Rust 开发者遇到的一个问题。作为驱动编写的示例以及比较 Rust 和 C 驱动的最佳方法，最好能在内核中有一些很好的参考驱动。然而，通常来说最好的做法应该是合并一个 Rust 驱动，并且该驱动能复制了现有的 C 驱动的功能。但是这种实现重复功能的做法并不受维护者的欢迎。他说也许应该允许一些不用于实际使用、仅供其他开发人员参考的重复驱动存在。

还存在一些其他挑战；上游的 block 层抽象的合并工作遇到了一些阻力。虚拟文件系统层的维护者 Christian Brauner 表示，他不反对合并这些抽象，但他更加希望别合入，也不希望马上有基于 Rust 的文件系统。他更愿意看到相对简单的某种实现，沿着 binder 驱动程序的思路，能显示事物是按预期工作的。

A driver soon?

DRM（图形）子系统的维护者 Dave Airlie 表示，如果他能搞定的话，将在接下来的几个发布版本中合并一个 Rust DRM 驱动程序。Christoph Hellwig 反击说，Airlie 愿意“让每个人的生活都变得很糟糕”，以便他可以玩他喜欢的玩具。Hellwig 表示，合并 Rust 将迫使其他人处理第二种语言、新的工具链和“具有奇怪语义的一些封装”。Dan Williams 表示，当前的情况“看起来就已经是成功了”，内核社区已经致力于 Rust。

Airlie 继续表示，目前很多 Rust 的工作都受到某种鸡和蛋问题的阻碍。在有用户之前，不能合并抽象，但需要这些抽象的代码却在等待着在多个子系统中先合入相关代码。结果，致力于 Rust 的开发人员正在携带着大量的补丁，以使他们的代码正常工作。要消除这个障碍，就需要在没有马上用户要用到的情况下引入一些抽象。Ojeda 同意这个问题一直在减缓进展，但表示他一直在努力不让维护者急于合并代码。具有讽刺意味的是，在网络协议栈里 Rust 开发人员不得不要求网络维护者放慢合并 Rust 代码的速度。

之后，对话的风向多次改变。Greg Kroah-Hartman 表示，合并 binder 驱动程序将是很好的下一步动作；它是独立的，有一个致力于维护的单一用户，并且不涉及内核的其他部分。Kees Cook 反驳了将 Rust 描述为“玩具”的说法，表示现在有很大的压力希望不要使用 C 来写新代码；Hellwig 回应说，开发人员将不得不用 Rust 重写一切，否则最终的使用两种语言的代码库将比现有的更糟糕。

Dave Chinner 担心维护者缺乏适当的专业知识来 review 正在合并的抽象逻辑。Airlie 回应说，维护者现在已经合并了很多 C API，而并不真正了解它们是如何工作的。在这个过程中犯了很多错误，但“我们仍然活得好好的”。当事物被证明是错误的时候，它们可以被 fix，如果代码推到了 upstream，修复将会更加迅速。

Ted Ts'o 对增加 Rust 代码将给维护者带来的负担表示担忧。他说，Rust 开发人员正在制定比过去更高的标准。合并良好的抽象是一回事，但是谁负责审查驱动程序，以及如何处理整个代码树中的改动？他表示，Rust 的努力正到达影响社区日益增长的地步。

Williams 指出，前一次会议已经讨论了让内核子系统迁移到新 API 的困难之处；现在，他说，有关迁移到全新语言的讨论出现了。Hellwig 表示，真正的问题在于 Rust 绑定往往与它们为之提供抽象的 C API 不同；新的 API 可能更好，但它们仍然是全新的 API。他说，应该首先修复 C API，使其能够直接被 Rust 代码使用。他建议，对于考虑引入 Rust 代码的每个子系统，应该首先花一两年的时间来清理其 API。Ojeda 表示，这种 API 改进在一些子系统中已经发生过了。

Linus Torvalds 表示，他看到了文件系统和驱动程序维护者之间的分歧。文件系统方面的开发人员往往更加保守，而驱动程序世界“就是西部牧场”。驱动程序作者往往不了解并发性，他说，驱动程序中有很多代码是错误的，也是无法修复的。因此，有兴趣引入新的语言来更好地支持开发正确和安全代码就有好处了。

Brauner 表示，Rust 可以帮助解决很多问题，因为编译器可以防止很多错误进入内核。但他担心几年后是否会有维护和开发支持。Airlie 再次提到具有 Rust 代码需求的开发人员，Cook 回应说，引入该代码的人 就是 维护者，引入该代码将会带来维护者。Airlie 补充说，这些维护者是内核社区希望吸引的那种年轻开发人员。

Chinner 表示，他希望看到一个在 Rust 中重新实现的 ext2 文件系统。它是一个完整的文件系统，广泛使用内核的 API，但仍然足够小，便于阅读和理解。如果 Rust 的 API 可以支持 ext2 实现，它们将足以实现其他文件系统。与此同时，ext2 实现将是维护者的好参考，他们可以将其与 C 版本进行比较。

Confidence

Ts'o 问社区何时才会足够自信，可以有模块是完全采用 Rust 编写的。他说，binder 可能是一个不错的开始，然后是一个更广泛使用的驱动程序。Airlie 表示，他正在考虑一个虚拟图形驱动程序，重新实现一个现有的 C 驱动程序。还有用于 Apple M1 GPU 的驱动程序。他感受到相当大的压力想要将其推到上游，并想知道是否有任何理由不应该保持这种状态。之后，他希望看到 Nouveau 驱动程序的重写。

Arnd Bergmann 表示，这些驱动程序可能没问题，但在处理像键盘驱动程序这样广泛使用的驱动程序之前，可能还需要相当长的时间；他说，对于广泛使用的驱动程序来说 toolchain 还没有做好准备。这引发了有关内核中经常发生的版本升级的问题，内核在 6.7 版本中升级到了 Rust 1.73.0。Bergmann 表示，这个升级过程最终会停止，一旦内核所依赖的重要特性稳定下来，将设置最低 Rust 版本。他说，他一直在努力将内核代码纳入 Rust 的持续集成测试，以确保随着编译器和语言的演变，它仍然能够正常工作。

Bergmann 表示，他在 Rust 能够使用 GCC 编译之前并不打算认真研究该语言。Torvalds 回应说，虽然他过去发现 LLVM Clang 编译器中存在问题，但现在他更容易在 GCC 中发现问题；他现在使用 Clang 进行构建了。Ojeda 表示，他正在寻找 gccrs 的开发人员资源；该项目目前有超过 800 个树外补丁，并且在此基础上仍有很多工作要做。支持 GCC 将需要一段时间，他说。

Ts'o 抱怨说，语言仍然不够稳定。这对于保密计算（confidential-computing）社区可能是一个特别重要的问题；他们担心安全性，因此也对那些需要向后移植到长期支持内核的补丁很关注。但如果这些内核是在不同的 Rust 版本上，那么这些补丁将会有问题。Ojeda 表示，尽管这是一个“疯狂的想法”，但可以考虑把 Rust 版本也 backport 回去。他认为，变更不会很频繁，因此不会成为问题。

在结束时，Torvalds 指出，多年来 GCC 的改动一直在对内核产生破坏性影响；Rust 肯定也会发生同样的事情，但最终结果将是一样的。该会议此时已经远远超时，于是被终止了。内核社区是否真正得到结论需要认真对待 Rust 了，这一点仍有待观察；几乎可以肯定在不久的将来将会有添加大量 Rust 代码的拉取请求（pull request）。

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

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

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