LWN：对加速器驱动的硬性要求！

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

Requirements for accelerator drivers

By Jonathan Corbet
September 27, 2021
Maintainers summit
DeepL assisted translation
https://lwn.net/Articles/870418/

8 月份的时候，内核社区内爆发了一场关于人工智能加速器（AI accelerator）的驱动程序的长时间的争论。图形加速器的驱动被要求至少要提供一个用户空间部分的开源实现（因为用户空间代码才是这些 driver 的主要逻辑存在的位置）。到目前为止，其他类型的加速器驱动程序还没有被要求也要达到这个标准，这在社区内造成了一些冲突，也给不同领域的开发者带来了不一致的体验。2021 年的维护者峰会讨论了这个问题，希望能创造一个更一致的政策。

Greg Kroah-Hartman 是子系统的维护者，他在没有遵照 open-user-space （用户空间代码也要开源）这个标准的情况下接受了一些加速器的驱动。他在会议开始时说，在没有明确提出标准的场景下，他无法对这些驱动程序的开发者说 "不"，他需要有个标准可以用来指给这些开发者从而拒绝他们。DRM（图形子系统）的维护者 Dave Airlie 说，他的子系统确实是有这类标准的，但他承认，这些标准很难作为一个普遍要求。他说，对开发人员说 "不"，是让开发人员努力把事情做好的最好方法。如果标准定得太低，开发人员就会把他们的代码扔进去，然后就消失了。说 "不" 的情况下他们会更加投入。

他继续说，我们需要对大局更加负责，这意味着我们需要关于内核驱动的硬件如何实际工作的信息。这对于使用内核 API 的某些领域的驱动程序来说尤其需要这些信息，特别是使用到 DMA-BUFF API 的那些驱动。DMA-BUFF 是一种驱动之间的接口机制，使用该 API 的新驱动将与其他 "已经通过了所有标准" 的复杂驱动来交互通讯。我们不希望通过与一个新的驱动程序、甚至其开发者还没有加入社区的驱动程序交互通讯来损害这些现有驱动程序的运行。

Airlie 说，引发大部分争议的 Habana 人工智能加速器驱动，实际上比大多数驱动质量都要更好。但它仍然会产生安全问题。类似这种驱动程序的开发者们并不都是擅长创建安全内核 API 的专家。Kroah-Hartman 说，如果像 Habana 这样的驱动程序被挡在内核之外，他们仍然会使用像 DMA-BUFF 这样的 API，但是没有人会知道这一点，情况就会更糟。但是 Airlie 重申，DMA-BUF 是他不希望被绕过的一条底限。

Kroah-Hartman 说，他可以理解这个规则对图形驱动的影响，但是对于像 Habana 这样的驱动，他没有可以适用的标准。Airlie 回答说，Habana 加速器本质上是一个 GPU；人们可以在它上面实现 OpenCL–这是他在 Habana 开源其编译器之前并没有意识到的。他问道，如果一个供应商正在制造一个专用于计算的显卡，为什么他们的竞争对手可以满足我们的标准，但是他们就不行？

因此，Kroah-Hartman 问道，具体来说符合哪个标准的的驱动，需要满足同时提供开源版本的用户空间实现？Airlie 说，Habana 驱动是作为 "非 GPU 驱动 "提出的，但现在它正在使用 DMA-BUFF。这就是标准了。现在 InfiniBand 子系统也在使用这个标准。

Arnd Bergmann 说，这里有几种情况。对于什么都可以运行的那些加速器，比如 GPU，它的驱动确实需要通过 DRM 子系统并遵守 DRM 的规则。不过，对于有更明确用途的设备，它们最好是采用定制的内核接口，并降低这里的合入标准。

Kroah-Hartman 说，维护者必须做出判断。很多新的子系统被提交给他，他需要对每个子系统都做出决定。他应该怎么做？Airlie 重申，应该在 DMA-BUFF 和 DMA fence API 上作为界限。"角落里的那些小驱动 "可以不需要满足很多规则就能合并，但加速器不可避免地会需要使用到 DMA-BUFF。在没有访问 DMA 或 graphics 的情况下，加速器就没有存在的意义了。他说，这些设备最开始时很简单，但一旦它们走向生产系统，就会变得更加复杂。Kroah-Hartman 同意坚持 DMA-BUF 这个标准。

Airlie 说，graphics 的一个问题是，所有的 GPU 都没有通用的用户空间 API，只有 "一个很小的提供可发现性的 API"。这些 device 差异非常大，以至于无法创建一个标准 API。但这意味着对特定驱动程序提供的 API 几乎没有什么控制。就像现在这样，图形开发人员经常在驱动程序中可以发现一些用户空间中从未使用过的接口。

他说，DMA-BUFF 的这个标准很好，因为使用该 API 就可以让开发者与专家开始交流。社区里面能有一个开发者来知道 device 的用户空间代码在哪里，那就非常有价值了。这样我们有可能在 review 中看到哪些接口是真正需要的，以及其他的一些信息。供应商需要发布针对他们设备的编译器，以便 DRM 开发者可以看到硬件的能力。例如，如果设备可以直接发起 DMA，那么 API 就必须防止 user 直接使用这种能力。

Torvalds speaks

这时，Linus Torvalds 插进来说，他想对 Airlie 提出的一些观点进行一些讨论。Airlie 来自一个拥有 25 年经验的子系统，这里有自己的历史信息和社区。开发者们知道这些 device 将是如何工作的。但是，当新人进来的时候，我们不想创造一个非常高的准入门槛。是的，他们第一次确实会做错一些事情，但是在我们让他们合入内核之前，他们都没有机会学会如何做正确的事。

出于这个原因，Torvalds 赞成接受新的代码，并让不同的团体自己犯错自己成长。毕竟，DRM 的开发者过去把很多事情都搞砸了，这也是走向他们自己目前的 API 的道路的必由之路。DRM 的开发者当初肯定不知道他们现在所知道的一切知识。像 Habana 这样的公司也是如此，他们会做错事情，但如果我们阻止他们，他们就永远不会把事情做对。这也是他让 ksmbd 和 ntfs3 文件系统进入 5.15 的原因。

换句话说，他继续说，社区应该对接纳新的子系统要持开放态度，但也应该更主动地把它们废弃淘汰出去。如果一个子系统给其他人带来了问题，那么它就要被淘汰掉。如果没有用户空间这一部分，为什么要留着它在 kernel 里？如果 Habana 驱动程序造成了麻烦，它就可以被扔掉了。

他说，安全问题是 "纯粹废话"。硬件工程师已经拥有了机器，我们都无法保护自己不受设备能做的事情的威胁。我们无法解决硬件层面的安全问题，但我们可以努力确保可维护性（maintainability）。不过，Torvalds 确实也说，Airlie 讲到 DMA-BUFF 的时候的观点是正确的。驱动程序大多是独立的，但使用 DMA-BUF 是它们开始相互交互的地方，这就会带来实际上的可维护性问题。

Tests

Kees Cook 说，代码质量是一个真实的问题，我们没有足够的自动化分析来确保内核代码的质量。他问，ksmbd 的测试到位了吗？一般来说，我们没有办法直接找到针对某一段特定代码的测试方案（如果有这么个测试方案的话）。他说，他不是 BPF 的狂热粉丝，但是 BPF verifier 就很全面，可以防止很多问题。

Ted Ts'o 说，syzbot fuzzing system 虽然可能很烦人，但它也是很不错的。网络文件系统（如 ksmbd）中就缺少一个好的 fuzzing 测试方案。每个加速器都有自己的指令集架构，这个问题会更加难处理。Airlie 说，如果没有人使用有测试覆盖的 API，那么这个测试就没有什么价值。这种测试对可维护性没有什么帮助，因为他们不能让维护者们知道，哪些 API 正在被经常使用。这就是为什么 DRM 开发者坚持要有一个非常活跃的用户空间程序，要有活力，并且有许多能回答出相关问题的开发者。

Chris Mason，作为一个一直在推动 vendor 将他们的代码纳入内核的人，他觉得社区正在创造一个环境来让人们觉得 NVIDIA 模式（专有驱动程序）变成了一个最有效的模式。让代码进入上游的难度越大，就越难说服 vendor 来做正确的选择。因此，降低标准似乎是一个正确做法。我们必须让供应商经历犯错的过程，也让他们感受到相关难处。

Torvalds 谈到了最近与一家大公司的谈话，他惊讶地发现，那里雇用的一些核心开发人员并不希望总是在 upstream 上工作。他们总是很担心他们所关心的一个工作场景，所以他们就一直在这个领域里面进行各种相关改动，而不去考虑更大范围的需求。他说，"upstream first" 是一个目标，但它不能作为一个硬性要求。我们希望开发者愿意与我们合作，而不希望成为他们必须要处理的一种束缚。这意味着我们必须要有一定的灵活性。

Kroah-Hartman 说，他想接受新的东西，使其开发者成为社区的一部分，让他们更关心我们。Airlie 回答说，供应商只关心客户，所以只有他们的客户关心我们，他们才会关心我们。Kroah-Hartman 继续说，我们必须一起合作工作，并且要接纳对方。我们不能在代码合并之前，强行创建一个多个竞争对手都要统一的 API。Mason 把这句话重新表述为 "如果我们不让他们进入餐厅，就没法让他们喝到 Kool-Aid 饮料"。

Ts'o 最后询问大家是否已经基本上达成共识了，从而结束了这次长时间的讨论。是否有什么可以说的来统一驱动程序的接受标准？Airlie 说，在使用 DMA-BUFF 和 fence API 的问题上，大家似乎达成了一致，没有人反对他的观点。关于如何发现到这条线是否被绕过的情况，大家进行了一些讨论。编者建议将这些接口移到 module namespace 中，几天后，Kroah-Hartman 发布了相关的 patch。

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

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