LWN: 非GPU的加速器驱动绕过了合入原则！

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

Not-a-GPU accelerator drivers cross the line

By Jonathan Corbet
August 26, 2021
DeepL assisted translation
https://lwn.net/Articles/867168/

一般来说，内核社区通常乐意合并那些可以正常工作的设备驱动程序，不太关心相关的用户空间代码是否真正可用。发生在用户空间的事情不在 kernel 的关注范围之内，也不受内核 license 的影响。不过有一个例外，那就是图形处理器（GPU）的驱动程序，如果没有可以正常工作的、采用了 freely-licensed 许可的用户空间软件的情况下，这些驱动就不能被合入 kernel。近年来，关于哪些驱动程序需要满足这个规则的问题已经被提出过好几次。这个讨论现在已经到了做最终决定是否要阻止 Habana 实验室的一些驱动程序的软件更新进入 5.15 内核。

上述 GPU-driver 的规则是由 DRM （direct-rendering）维护者 Dave Airlie 在 2010 年划定的界限。大多数 GPU 驱动的内核侧软件只是用户空间和设备之间的一个简单通道，实现了类似于网络连接的功能。这些驱动程序的真正复杂逻辑都放在了用户空间的软件组件中，而它会利用内核提供的通道来通过专有协议（通常是这样）从而控制 GPU。DRM 的维护者长期以来一直认为，如果用户空间没有一套已经实现好的软件，那么他们就无法判断、维护或测试驱动程序的内核部分代码。这个原则，他们已经坚持了十多年，并且认为这是该子系统在这段时间内取得的进展的一个重要原因。

就其本质而言，GPU 是一个经过优化的加速器，能够比最快的 CPU 还要更快地进行某些类型的处理工作。graphics 是这些加速器广泛得到使用的第一个场景，但肯定不是最后一个。最近，针对机器学习任务的加速器领域正在快速发展。其中的一个加速器，Habana Gaudi，已经得到了 Linux 内核的支持。

Gaudi 驱动的合入，引起了一些讨论，是关于如何处理这些 non-GPU 加速器的。这个驱动没有经过 DRM 代码仓库合入，也就没有遵守 DRM 子系统的上述原则，因此它进入了 mainline kernel 但实际上并没有相应的 user-space 部分。这一点后来得到了纠正（基本上纠正了，后文详述），但是 DRM 的开发者对这个过程感到并不满意，他们认为这个合入过程绕过了他们花了多年时间捍卫的原则。就在一年多以前，其他几个加速器驱动程序的到来就曾经引发了一场关于这些驱动程序是否应该被当作 GPU 对待的讨论，当时并没有明确的结论。

在过去的几个月里，Habana 驱动成为了一些类似讨论的引爆点，在 6 月底和 7 月初的时候讨论很激烈。现在的问题是该驱动的一个扩展功能需要使用到内核的 DMA-BUFF 和 P2PDMA 功能，用来在设备之间移动数据。这些子系统本来是为了能配合 GPU 驱动而开发的，并且因此被一些 DRM 开发者视为内核的 GPU API 的一部分。从这个因素来说，使用这些子系统的驱动就应该受到 GPU 子系统 merge 规则的约束。或者，就像 Airlie 在他反对合并 Gaudi 的改动时的说法：

我不支持在上游内核中为该驱动添加 dma-buf 或 p2p 功能。我们需要划个界限来界定某个驱动是不是 "一个 DRM 驱动 "，从而避免这类 driver 绕过我们对用户空间的要求，而我认为这（支持 dma-buf 或 p2p）就是我们该使用的界限。

这个驱动被合入 misc，理由就是它并不是一个真正的 drm/gpu 驱动，所以不必接受我们的用户空间相关的规则。

而将 dma-buf/p2p 功能添加到这个驱动中的话，就表明它确实符合 gpu driver model，并且应该遵循 drivers/gpu 相关规则，这就是大多数加速器和 GPU 的一个区别。

正如 DRM 开发者 Daniel Vetter 所承认的，这里其实有个误会，确实是有一个 free 的用户空间的 Gaudi driver 的。目前还缺少的是用来生成那些实际驱动该设备工作的指令流的编译器。Vetter 说，如果没有编译器，那么虽然当前代码是存在的，但是 "我们仍然无法对 driver stack 进行调试"。他进一步阐述道：

如果没有编译器，我可以按照我的设计来正常使用这个硬件吗？

如果答案是否定的，那么从本质上讲，你用你的上游驱动所做的唯一一件事就是用来获得了 upstream 驱动的所有好处，而 upstream 却没有得到任何好处。我们无法直接使用你的这一套 driver。当然我们可以使用 queue 队列，但事实上我们不能提交任何有实际价值的任务。

在讨论的过程中，DRM 的开发者们一直在明确说明，他们想要一个有效的、free 的用户空间的实现。它不一定是交付给客户的代码，只要它足以让人理解驱动程序的整体工作原理即可。不过，对某些人来说，索取编译器的要求有点过分了。Habana 的开发者 Oded Gabbay 曾这样描述 DRM 子系统的要求：

我真的认为 dri-devel 的合并标准是过于极端了，并且事实上赶走了许多想为内核做贡献但不能或不愿开放其 software IP 和 patent 的 AI 加速器公司。

我认为期望人工智能初创公司（它们在深度学习领域的占了 90%）能跟公司边界之外的人进行合作，这是不现实的，尤其是用户空间这一部分，这是公司真正的知识产权所存在的地方。

当然，Linux 内核开发过程的核心就是要求能跟公司之外进行合作。DRM 子系统并不是唯一提出这种要求的。Vetter 回应中专门之处，kernel 社区也不会接受那些没有能正常工作的 free compiler 的新 CPU 架构。

多年来，经常出现厂商在希望他们的硬件能与 Linux 一起工作的同时、还希望将他们的 "知识产权" 保留给自己的事例。这类困难已经被克服了很多次，因此我们所使用的 kernel 中获得了对硬件更加广泛和完善的支持。要克服这类困难至少需要做两件事：客户要求获取 free driver，并且开发社区对专有驱动程序的强烈反对。需求方必须自行开发（而且经常是这样做的），但内核社区一直在努力工作，从而能对于驱动代码维持一个一致的立场，并对外保持沟通。2008 年发表的声明（https://lwn.net/Articles/287056/ ）就是一个例子。因此，社区内有一个共识，涵盖了与专有驱动程序相关的许多领域。例如，人们很难看到赞同 export symbol 来让这些驱动程序受益的观点。

这一系列正在进行的讨论表明，当涉及到加速器设备的驱动程序的要求时，内核社区目前还没有达成共识。这就造成了这样一种情况：如果通过 DRM 子系统进行合并会被一些规则所拒绝的代码，可以通过另一条路径来进入内核，从而绕过了这些规则。当然，这样以来这些规则就形同虚设了。对这个前景的担忧不仅仅存在于 DRM 社区，media 子系统开发者 Laurent Pinchart 也写道：

我怎么强调都不为过，我们花了多大的力气才开始让 vendor 厂商们加入进来，而且目前的情况实际上还是很脆弱的。如果我们现在发出一个信息，所有这些驱动都可以经过 drivers/misc/ 来绕过所有规则直接合入，那么这将会使得十年来的工作都完全浪费了。

要避免这种结果，就需要让内核开发者和（尤其是）子系统维护者能达成某种协议。这通常是一项具有挑战性的任务。

在 Gaudi 驱动的案例中，Greg Kroah-Hartman 回答说他已经把有争议的代码拉到了他的代码仓库里了。因为后来的反对意见，他放弃了这项工作，并承诺今后有空的时候他会再 “多说一些”。暂时放弃这个 patch 有助于平息事态，但它并没有解决根本的分歧。总有一天内核社区必须要针对加速器驱动的规则达成某种结论。如果不这样做的话，我们可能会看到更多的的 non-GPU 驱动进入内核，以及看到随之而来的许多纷争。

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

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

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