LWN：显卡驱动以外的驱动也需要配有符合自由软件协议的用户空间程序吗？

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

Free user space for non-graphics drivers

By Jake Edge June 3, 2020 原文来自：https:/lwn.net/Articles/821817

主译：DeepL

在内核显卡领域，一直以来都有一条 "界线"，那就是禁止merge那些没有配套的free-software user-space driver的kernel driver。不这样的话就没有办法测试完整的功能，内核开发者无法验证驱动能否正常运行以及是否安全。对内核驱动的修改可能会导致user space发生不可预见（且无法测试）的问题。不过最近，我们已经看到了一些其他类型的设备，它们具有复杂的驱动程序但并不具备可用user space对应功能，就已经被提议合入kernel。其中至少有一个被merge了，但在这一点上，目前的观点风向也许已经转向了反对这些类型驱动程序——或者至少说反对其中一部分驱动。

5月中旬，Jeffrey Hugo发布了 "Qualcomm Cloud AI 100"设备的RFC patch，该设备是一个带有特定应用集成电路（application-specific integrated circuit, ASIC）的PCIe卡，针对 "深度学习 "的计算。该设备也被称为QAIC device，它提供了一个调制解调器主机接口（modem host interface, MHI）的control path和一个DMA引擎用作data path。驱动把这些功能都以Linux字符设备的形式暴露出来，用ioctl()命令来访问data path。

早在2010年就定下文章开头这个规则的Dave Airlie，在询问为何QAIC driver就能得到与众不同的待遇。它有一个面向用户的API（他称之为 "uapi"），但是这个API并没有open-source程序使用它，也没有相关的test代码。

Although this isn't a graphics driver, and Greg [Kroah-Hartman] will likely merge anything to the kernel you throw at him, I do wonder how to validate the uapi from a security perspective. It's always interesting when someone wraps a DMA engine with user ioctls, and without enough information to decide if the DMA engine is secure against userspace misprogramming it.

Hugo说，他计划把一套这种设备 "交到Linaro手中，这样就可以把它加入到KernelCI中"。首先，他需要得到高通公司其他人的许可。不过除此之外，没有看到其他有用的user space这边的应用程序。

Regarding what the community could do on its own, everything but the Linux driver is considered proprietary - that includes the on device firmware and the entire userspace stack. This is a decision above my pay grade.

I've asked for authorization to develop and publish a simple userspace application that might enable the community to do such testing, but obtaining that authorization has been slow.

Airlie没有料到的是，Kroah-Hartman表示，在拿到这些信息（和代码）之前，他不会进一步review这个驱动程序；此外，他不会merge，他也会积极反对任何人merge这个driver：

Ok, that's a decision you are going to have to push upward on, as we really can't take this without a working, open, userspace.

Especially given the copyright owner of this code, that would be just crazy and foolish to not have open userspace code as well. Firmware would also be wonderful as well, go poke your lawyers about derivative work issues and the like for fun conversations :)

Hugo说他会尽力试试，但似乎并没有多大把握能满足kernel开发者提出的需求。另一方面，Daniel Vetter也对Kroah-Hartman的立场感到惊讶：

So the merge criteria for drivers/accel (atm still drivers/misc but I thought that was interim until more drivers showed up) isn't actually "totally-not-a-gpu accel driver without open source userspace".

Instead it's "totally-not-a-gpu accel driver without open source userspace" and you have to be best buddies with Greg. Or at least not be on the naughty company list. Since for habanalabs all you wanted is a few test cases to exercise the ioctls. Not the entire userspace.

Vetter指的是之前merge的Habana Labs kernel driver，当时他和Airlie等人都很反对merge这个driver。当时指出的问题与QAIC driver现在的问题大同小异，但这次的结果跟上次却有所不同。Kroah-Hartman表示，他主要是担心" the copyright owner of this code"，这当然是指高通。该代码实际上由Linux基金会（Kroah-Hartman隶属的公司）拥有版权，来自Code Aurora Forum，该forum是Linux基金会的合作项目。高通创新中心（QuIC）是该组织的主要成员。

他指出，Habana Labs在kernel driver合并后已经将其library code作为open source发布，所以上次的问题已经圆满解决。但他确实承认，他之前对这类driver的看法是错误的：

Also, to be fair, I have changed my mind after seeing the mess of complexity that these "ioctls for everyone!" type of pass-through these kinds of drivers are creating. You were right, we need open userspace code in order to be able to properly evaluate and figure out what they are doing is right or not and be able to maintain things over time correctly.

So I was wrong, and you were right, my apologies for my previous stubbornness.

最近微软提交的DirectX驱动也是类似的情况。Sasha Levin在5月19日发布了一个RFC patch：

The driver exposes a paravirtualized GPU to user mode applications running in a virtual machine on a Windows host. This enables hardware acceleration in environment such as WSL (Windows Subsystem for Linux) where the Linux virtual machine is able to share the GPU with the Windows host.

至少目前来说，这个应用场景根本不是关于graphics的，它的目的是为Windows系统上的Linux guest提供一种访问GPU计算能力的手段。但宣布该功能的blog似乎表明，graphics支持后面也快出来了。Vetter表示，按照文档里的规定，显卡驱动需要有一个free（自由软件）的user space才能合入upstream，但是这次似乎没有按照规则来：

From the blog it sounds like the userspace is all closed. That includes the hw specific part and compiler chunks, all stuff we've generally expected to be able to look [at] in the past for any kind of other driver.

他建议，既然驱动程序不是针对graphics的，那么它可以移动到kernel代码中的其他目录（比如drivers/hyperv）。Airlie也有类似的看法：

This is a driver that connects a binary blob interface in the Windows kernel drivers to a binary blob that you run inside a Linux guest. It's a binary transport between two binary pieces. Personally this holds little of interest to me, I can see why it might be nice to have this upstream, but I don't [foresee] any other Linux distributor ever enabling it or having to ship it, it's purely a WSL2 pipe. I'm not saying I'd be happy to see this in the tree, since I don't see the value of maintaining it upstream, but it probably should just [exist] in a drivers/hyperv type area.

但他有点担心，如果今后graphics功能也会添加进来的话，那现在将其合并到Hyper-V tree的话可能会导致日后很麻烦。但微软的Steve Pronovost表示，虽然未来可能会支持graphics，但不会使用这里提出的这个驱动程序，因为它是严格针对GPU计算情况的。他说他们正在进行在WSL上支持Linux GUI应用程序的工作，但这会是用远程桌面协议（RDP）和Wayland compositor来配合完成，这部分工作将是完全开源的。

Levin指出，他个人很希望能把讨论到的这个驱动程序中配套的user-space代码也开源公布出来，"并希望我能为此做些事情"。他也不反对将驱动程序移到graphics tree之外，似乎这样可以往前走。他还指出，提出RFC "并不意味着'我们现在就想要合入upstream'，而是在说'让我们一起想办法把它做好'：）"。

这样看来，QAIC driver将被束之高阁，而微软的驱动或许能有机会合入mainline，尽管两者都没有什么free user-space code，也就没法进行针对性的测试。部分原因可能是由于高通多年来与内核开发社区的关系不睦。除此之外，QAIC设备似乎是一个更复杂的驱动，有更多可能性会导致在人们未发觉的情况下出问题。但是，微软的驱动程序还没有被merge，我们将不得不等待，看看它缺乏free user space程序是否阻碍了它的merge。

这类driver肯定不会就这么几个。现在的趋势是设备是由user space来直接进行逻辑控制，内核只是作为用户空间和设备之间传递专有代码和数据的管道，只有设备制造商才真正了解设备内部的实际情况。对于设备制造商来说，让自己的驱动进入mainline显然是有好处的，但这样做对社区有什么实际的好处吗？正如Airlie针对DirectX驱动所说的这番话："[......]我完全看不出这能给Linux生态系统带来什么价值，我认为在给上游增加负担的时候，你必须提供一些价值。"

拥有这些设备的用户可能会受益，因为他们可以直接从自己的Linux发行版中直接得到支持了，设备制造商也能得到内核开发者的 "免费维护"，但社区却只得到了一堆并不是特别有用的代码，而且增加了风险、可能会在未来造成问题。这听起来跟通常的free-software的工作模式。幸好，内核开发者提供了一个功能很完善的平台，设备制造商可以利用这个平台来销售和运行他们的设备，只是他们需要自己维护和发布自己的驱动程序就可以了。

全文完

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

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

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