关注了就能看到更多这么棒的文章哦~
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 深度文章以及开源社区的各种新近言论~