Linux News搬运工
关注了就能看到更多这么棒的文章哦～
A tale of two troublesome drivers
By Jonathan Corbet
April 12, 2024
ChatGPT translation
https://lwn.net/Articles/969383/
内核项目在每个开发周期都会合并数十个驱动程序，几乎每一个驱动程序都是完全没有争议的。然而，偶尔会有驱动程序提交引发更广泛的问题，导致长时间的讨论，甚至可能遭到反对。目前就存在两个与网络子系统有关的独立驱动程序，其中一个陷入僵局是关于是否以及如何将所有设备功能提供给用户空间，而另一个则因为驱动的设备仅在单个公司内部可以获取到从而引发争论。
mlx5ctl and fwctl
mlx5ctl 驱动程序并不是一个新问题；它在 2023 年 12 月已经被报道过了。简而言之：这个驱动程序实现了一个传输通道，允许用户空间查询和操纵 mlx5 设备上的参数（该设备提供一系列网络、RDMA 和 InfiniBand 功能），但是内核部分对这些参数没有任何理解。支持者说，这个驱动程序是必需的，以便为用户提供配置和调试硬件所需的访问权限，特别是在其他直接与硬件通信的方法在受限系统（locked-down system）中不可用的情况下。反对者则认为，这是在规避正常的规范开发流程，该流程规定了设备参数如何导出（export）到用户空间。
Saeed Mahameed 在 2 月初发布了 mlx5ctl 补丁系列的 新版本，表示：“我们仍然认为 mlx5ctl 是合理的，并符合更广泛内核社区价值观”。Christoph Hellwig 回复 时承认并抱怨了“子系统维护者的过度干涉”，这阻碍了该驱动程序的合并。网络维护者 Jakub Kicinski 同意 “这个干涉是个遗憾”，但也坚持认为这个驱动程序不应该被合并：“我们对用户空间到固件接口不透明的情况有明确的规定”。除此之外，那时没有太多其他关于提交的讨论。
然而，到了 3 月初，Jason Gunthorpe 提出了一个名为“fwctl”的新子系统的 提议，这将成为类似 mlx5ctl 的驱动程序的家园。他写道，现代设备往往配备了一组大量的可调参数，控制其功能的许多方面；如果用户要能够使用他们的硬件，这些参数就需要被用户空间访问。
fwctl 的目的是定义一组有限的共同规则，如下所述，允许用户空间安全地构建和执行设备 FW 内的 RPC。这些规则作为操作系统和 FW 之间正确设计的 RPC 接口的协议。作为一个 uAPI，该子系统提供了一个薄薄的发现层和一个通用的 uAPI 来传递 RPC 并收集响应。它支持一套用户空间库和工具系统，这些库和工具将使用这个接口来控制设备。
该提案详细介绍了通过 fwctl 接口可用的功能类型。它还涵盖了不能提供的功能，包括对任意内存进行 DMA、操纵内核内存或驱动本身之外的子系统，或提供诸如发送网络数据包之类应由其他子系统处理的功能。
与以前一样，对于 mlx5ctl 和 fwctl，主要的反对意见来自于 Kicinski。他 将 这项工作的正当性描述为“烟雾和镜子”，称这是制造商“尽可能隐藏你认为是你的专有优势在 'AI 淘金潮流' 中”的一种方式。复杂的硬件，他 说，不需要绕过内核的介入与固件通信的后门；他举例引用了 Meta（他的雇主）使用的网络接口。他 质疑 fwctl 驱动程序的限制是否会得到执行，并表示该对话似乎没有朝着有益的方向发展：
或者我们应该再次讨论开放性和构建共同抽象的过程，以及供应商如何说他们的基本配置方式是如此特殊，这仅仅是为了调试和安全还是因为其他原因。
在这里没有任何人希望尝试构建一个共同的接口。
Kicinski 曾多次表示，这种功能应该通过像 devlink 这样的 API 提供，其中参数在经过社区审查后暴露出来，这种审查的目标之一就是强制在来自不同制造商的硬件之间实现一致。他 抱怨 说，他迅速审查建议的 devlink 开关的提议被寻求 fwctl 接口的供应商忽视了。
在另一方面，David Ahern 断言，fwctl 就是 Kicinski 寻找的共同接口。Gunthorpe 说，所有复杂的设备都需要特定于硬件的工具来配置它们以满足客户的需求。Meta 之所以不需要这样的工具，仅仅是因为作为一个大客户，它能够从供应商那里预先配置好硬件；小客户无法获得那样的服务。供应商多年来一直在提供这些工具，他说；fwctl 只是为它们提供一个共同的接口。
Gunthorpe 补充 说，devlink 方法的问题在于，除了过程缓慢且痛苦之外，它是注定要失败的。要有用，接口必须能够处理设备提供的所有参数：
就配置（configuration/provisioning）而言，实际上是要么全有要么全无。
如果一个特定的站点只能配置所需的 90% 的东西，因为你会 NAK 缺失的 10%，那么它仍然是不可用的，并且对所有人都是一种浪费。
你从来没有展示过通过你的 devlink 方法实现 100% 的途径。事实上，我相信你直截了当地说过，100% 是不可实现的。
然而，Kicinski 对这个论点并不 接受，称其中许多开关是“破解和懒惰的权宜之计”。
截至撰写本文时，这个讨论看起来与 12 月份时相比没有更多进展。立场只是随着时间的推移变得更加坚定。最终，这个驱动程序（或未来的 fwctl 子系统）的命运可能取决于 Linus Torvalds 是否愿意允许网络维护者阻止合并一个大多数人认为与网络子系统无关的驱动程序。
A network interface for one
在四月初，Alexander Duyck 发布了一个名为“fbnic”的驱动程序 用于定制网络接口卡，该接口卡仅在 Meta 内部使用。这引发了 Jiri Pirko 的 立即质疑，他想知道为什么社区需要一个没有人能够获得的设备的驱动程序。Duyck 回应 说，把驱动程序推向上游将使维护更容易，后续引入驱动程序中实现的新网络功能更容易，并且该公司也可能有一天会公开一些硬件信息。Pirko 并不认同，并表示不应合并该驱动程序。
Duyck 称 这种理由是“武断和反复无常的”。他说，该驱动程序将在 Meta 有大量用户。过去已经向内核添加了其他专有设备；在对话的其他地方，Intel IDPF 驱动程序 被提及为一个例子。驱动程序经常出现在尚未销售的设备上，甚至可能永远不会上市。拒绝该驱动程序，他说，是对 Meta 的“一些缺乏诚意”的指控。
Kicinski 试图在某种程度上重定向讨论，他表示不希望成为评判公司“诚意”的人。他说，社区必须根据项目的利益和更广泛的用户群来做出决定。那时，他并没有说他认为是否应该合并该驱动程序。然而，其他人，比如 John Fastabend 和 Paolo Abeni，则认为 fbnic 看起来是良好的代码，而且无论如何，它只是一个网络接口驱动程序，没有潜在危害其余内核的地方，所以没有理由把它排除在外。
然而，Gunthorpe，虽然不反对合并 fbnic，还是 提出了一些担忧。有一种强烈的感觉，即代码不应该仅仅出于支持专有用户空间代码的目的而合并，他说，“这个提交显然模糊了这条界线”。他 说，这可能会导致未来出现问题，因为驱动程序添加了更多功能。
当 Andrew Lunn 提到 mlx5ctl 的讨论时，要求 Duyck 显示此设备不需要单独的固件调整驱动程序，Kicinski 说，展示这一点不会改变任何人的想法。Ahern 建议，在未来，“不可避免的生产问题”出现时，类似 mlx5ctl 的单独驱动程序很可能会成为必需。
然而，最大的担忧可能是由 Kicinski 表达 的：如果内核其他地方的更改破坏了驱动程序，为其用户创建了回归问题会怎样？由于整个社区无法测试该驱动程序，因此很难避免这种问题，甚至更难修复；这可能会导致内核更改被撤销。在这种情况下，像 fbnic 这样的私有驱动程序可能会阻碍内核的发展。
因此，尽管 Kicinski 最终 得出结论说“有广泛的支持来合并这个驱动程序”，但他还说，需要有一套略有不同的规则来管理私有设备的驱动程序。这些规则将包括“较弱的 '无回归' 保证”和对驱动程序维护人员积极参与重构子系统接口工作的期望。在缺乏这种参与的情况下，私有设备的驱动程序可能会被从内核中删除。Pirko 最终 同意，如果该驱动程序被标记为属于这种新制度（这必须有文档记录），“让其进入也可以”。
因此，fbnic 驱动程序最终似乎有望被合并。未来可能也会对 mlx5ctl 以某种形式做出类似的决定。Linux 内核之所以能够达到现在的地位，是因为它不拒绝让用户访问他们硬件的全部功能，而且现在看来它似乎不太可能采用这样的政策。然而，更难的问题是猜测还需要多少长篇讨论才能做出这个决定。
全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。
长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～
