LWN：DMA mapping中使用Rust抽象遇到阻碍！

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

Resistance to Rust abstractions for DMA mapping

By Jonathan Corbet
January 30, 2025
Gemini-1.5-flash translation
https://lwn.net/Articles/1006805/

尽管使用 Rust 编写设备驱动的道路并非一帆风顺，但我们已经取得了稳步进展，并且这个目标也接近实现了——至少对于某些类型的驱动程序而言是这样。设备驱动程序需要能够为直接内存访问（DMA, Direct Memory Access）传输设置内存区域；这意味着 Rust 驱动程序将需要一组抽象接口来与内核的 DMA 映射子系统交互。然而，这些抽象接口遇到了阻力，这可能会阻碍整个 Rust-for-Linux 项目的进展。

DMA 传输直接在 RAM（Random Access Memory, 随机存取存储器）和目标设备之间移动数据，而无需 CPU 的参与。如果没有 DMA，很难获得任何合理的 I/O 性能，因此几乎所有设备都支持它。然而，要使 DMA 正常工作，不仅仅是将内存地址传递给外围设备那么简单；还有许多问题需要处理，包括保持缓存一致性、确保页面驻留在 RAM 中、处理设备特定的寻址限制、编写 I/O 内存管理单元等等。此外，当然，每个架构的处理方式都不同。DMA 映射层的作用是将大多数这些问题隐藏在设备驱动程序之后，提供一个与架构无关的接口。

使用 Rust 编写的驱动程序需要进行 DMA 操作，因此它们需要访问 DMA 映射层。已经有一些补丁在流传，旨在提供对该层的部分访问支持；Abdiel Janulgue 在 1 月初发布了 一个版本的相关工作。这个系列添加了一个小的 Rust 模块，其中包含足够的支持来为驱动程序设置相干映射（coherent mappings，在缓存相干内存中的长期映射）。这项工作只涵盖了 DMA API 的一部分，但对于较简单的设备来说已经足够了。即将到来的驱动程序将需要这些抽象接口。

但是，Christoph Hellwig 对 DMA 映射层做了大量工作，他拒绝了这个提交，并附上一条消息，内容是：“请不要在 kernel/dma 目录中放置任何 Rust 代码”（尽管该补丁实际上并没有在该目录中放置任何代码）。在被追问时，他补充说，开发人员应该将这些抽象接口保留在自己的代码中，并且表示他对维护多语言代码不感兴趣。他总结说，Rust 开发人员应该自己保留他们的包装代码。

Danilo Krummrich 指出，所提出的抽象接口正是这样做的——将 Rust 代码与其余代码分离开来：“我们编写了一段 Rust 代码，它为所有 Rust 驱动程序抽象了 C API，我们主动提出自己维护这段代码”。此后，对话沉寂了几天，然后 Krummrich 说：“由于到目前为止还没有收到回复，我假设我们可以自行维护 DMA Rust 抽象接口”。

然而，Hellwig 明确表示他并不赞同这个计划。他不希望 Rust 代码出现在 DMA 层的任何地方，并且其他人会维护它的事实并没有改变他的观点。他说，添加另一种语言（他明确表示他指的是任何语言，而不仅仅是 Rust）将使整个 Linux “无法维护”。这暂时使对话陷入了停顿。

如果没有 DMA 支持，就不可能用 Rust 编写有趣的驱动程序。因此，Rust-for-Linux 开发人员目前面临的一个选择是放弃整个项目，转而寻找一个不那么令人沮丧的项目来做。尽管这个选择可能很吸引人，但它可能仍然不是他们的首选。

另一种方法是按照 Hellwig 的建议，将抽象接口放入每个需要它们的驱动程序中。然而，这并不是实现更易于维护的内核的途径。当 DMA API 发生变化时（这不可避免），需要逐个修复大量的驱动程序，而不是修复一组供所有驱动程序使用的抽象接口。因此，对于相关的开发人员来说，这可能也不会出现在选项列表的顶部。

还有一种方法可能是将 DMA 抽象接口隐藏在 Hellwig 的视线之外——换句话说，不要放在 kernel/dma 目录中。到那时，它就变成了 DMA API 的另一个用户，理论上，它不会受到比任何其他驱动程序更多的审查。这个想法的唯一问题是，Janulgue 的补丁已经这样做了，但还不够。

总有一天，需要对这个问题做出更明确的回答。Krummrich 试图通过 一份说明来促成此事，要求 Linus Torvalds 或 Greg Kroah-Hartman 对这些抽象接口做出决定。其他 Rust 开发人员 重申，他们将负责维护这段代码，并且它不会影响 DMA 子系统。Jason Gunthorpe 质疑了最后一种说法，他指出，由于一个 Rust 构建问题，6.14 的 pull request 被推迟了，但 Kroah-Hartman 回答说，这是一个“由于假期而被人们错过的工具问题”，而不是 Rust 代码阻碍开发的例子。但他和 Torvalds 都没有就所讨论的代码是否会被合并做出任何决定。

通过允许 Rust 进入，内核社区已经决定——至少是暂时性的——它确实愿意维护一个多语言代码库。也许，目前，将 Rust 代码驱逐到内核边缘的想法是有道理的，因为 Rust 仍然被视为一个持续的实验。如果最终确定 Rust 实验失败了，那么如果现有的 Rust 代码被限制在边缘，则将其撤回会更容易。

但 Rust 实验被这样判断的可能性似乎越来越小。Rust 显然可以用来编写内核代码，并且这样做似乎有一些显着的优势。如果实验确实成功了，那么在某个时候，该语言将需要被视为内核中的一等公民。随着时间的推移，“我不想处理一种以上的语言”将成为反对用 Rust 编写的贡献的越来越站不住脚的理由。

那一天可能还需要一段时间才能到来。已经过度劳累的内核维护人员将不得不抽出时间来充分学习 Rust，以便在其子系统中对其进行管理。新来的 Rust 开发人员可以承担其中的一些负担，但他们也需要时间来获得接近当前维护人员所拥有的经验水平——内核社区非常依赖这种经验。这种对像内核这样庞大的代码体的重大改变，从来都不是一件快速或容易的事情；到目前为止，进展顺利，但未来还会有更多，可能更难的障碍需要克服。

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

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

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