在最近举行的维护者峰会上,人们普遍认为Rust实验应该继续进行,Rust代码进入内核的道路已经很清晰。但是这种高屋建瓴的观点无法完全考虑到Rust工作在推进过程中不可避免会出现的棘手细节。最近在nouveau邮件列表上的一次讨论可能逃过了许多人的注意,但它突出了一些问题,这些问题在重要的Rust代码进入主线内核时必须解决。

首先,一些背景信息:nouveau驱动程序处理NVIDIA GPU。多年来,它是一项坚定的逆向工程工作的产物,在没有任何来自NVIDIA的帮助的情况下完成的;它在2009年的2.6.33版本中首次合并到主线内核中。最近,NVIDIA在自由软件支持其产品方面的态度有所改变,一直在帮助nouveau的开发。Ben Skeggs,多年来一直在从事nouveau工作,最近在NVIDIA就职。

Nouveau已经达到了合理的功能水平,但内核的DRM（图形）子系统的开发者已经在着手替换它,至少是针对较新的GPU。具体来说,Nova项目已启动,旨在为NVIDIA GPU创建一个新的驱动程序。与nouveau不同,Nova将使用Rust编写。参与开发的人认为,使用Rust是应对不断变化且无法提前通知的固件接口的最佳方式。Nova是一个相对年轻的项目,可能要等几年才能进入主线。

完全不同的另一部分内核是虚拟功能I/O（VFIO）子系统。简单来说,VFIO是一个用于控制I/O内存管理单元（IOMMU）的接口,可用于安全地将设备访问权限授予用户空间进程。IOMMU将确保设备只能访问属于使用它的进程的内存,从而防止设备（有意或无意）覆盖系统的其他部分。VFIO通常用于运行虚拟化guest的系统;每个guest可以获得它需要的设备访问权限,同时保持系统整体的安全性。

再补充最后一个角色:9月下旬,Zhi Wang发布了一套23部分的补丁集,实现了NVIDIA GPU的新"vGPU"功能。云系统中GPU访问的需求正在增加,以便我们都可以享受到大型语言模型不请自来出现在生活的每个方面的好处。vGPU补丁使云服务提供商能够轻松地为虚拟机提供一个或多个GPU的访问权限,并在出现争用时仲裁这些GPU的使用。NVIDIA显然认为,这个功能将使其GPU更吸引云服务提供商,因为后者被认为会购买大量硬件。符合NVIDIA更友好的上游态度,所有这些工作都瞄准了主线内核。

这个新的子系统,正如人们所预料的那样,是基于VFIO的,这意味着内核已经导出的用于虚拟设备控制的接口将适用于NVIDIA GPU。这个决定是无争议的。但是vGPU工作也依赖于nouveau驱动程序来访问硬件,并对nouveau进行了重大修改,以增加它所需的支持。这个方面引起了Nova背后开发者的注意,他们担心将这一功能建立在他们正在努力替换的驱动程序之上。计划是由Nova管理的芯片组将由Nova驱动,所以自然希望看到所有这些工作都在那里完成。

Danilo Krummrich询问了vGPU的长期策略:"这更像是一个概念验证吗?你打算在Nova上进行一般性工作,并为Nova提供vGPU支持吗?"Jason Gunthorpe,似乎在新子系统的设计中扮演了一定角色,回答说"这旨在成为客户将使用的真正产品,而不是概念证明"。他希望尽快合并它。他最后说:"作为一个商业产品,这将被大规模地回移植到许多旧的内核中,如果不是完全用C编写的话,这将更加困难/不可能。"

换句话说,新的vGPU子系统将被发行商（以及大规模用户）广泛回移植到"企业"内核中,这些内核的核心在Rust支持引入主线之前就已经存在了;Gunthorpe估计,目标系统上运行的内核中只有10%是基于6.0或更新版本的。由于最初的Rust支持直到6.1版本才引入,即使现在也还远未完成,任何Rust依赖性显然都会使vGPU的回移植变得更加困难,如果可能的话。结果可能是vGPU子系统根本无法进入这些旧内核,这将令许多相关人员（和公司）失望。因此,Gunthorpe得出结论,vGPU目前必须仍然基于nouveau,Nova项目必须设法接受这一点。

Krummrich承认目前使用nouveau是一个合理的方法,但担心增加Nova会导致内核中功能的重复。为了避免这种情况,他说,需要达成一致,vGPU开发人员将长远地致力于帮助Nova的开发,并将vGPU迁移到Nova的基础之上。Gunthorpe同意Nova总有一天可能成为vGPU的基础,但指出,而vGPU是一个可能很快就会合并的可用驱动程序,Nova却还不存在;"让我们不要过于远见卓识了"。

接下来的讨论有时很激烈,参与者似乎并没有完全理解彼此。Gunthorpe建议创建一个核心驱动程序(用C编写),只提供足够的功能来让更高级的驱动程序与设备通信;nouveau和Nova都可以建立在这个核心驱动程序之上。但DRM维护者Dave Airlie坚持,最底层必须使用Rust:

核心必须使用Rust,因为NVIDIA有一个不稳定的固件API。不稳定的固件API不仅仅是一些命令编组,而是深入到其中,比如内存大小要求、基本消息队列布局和编码、固件初始化过程。这些都可能随时变化,而不会考虑上游开发,所以上游开发需要尽可能地与这些隔离。使用Rust可以提供这种隔离层。 他建议可以有计划地进行过渡,以尽可能减轻VFIO方面的负担。Gunthorpe回答说:"我们现在无法在VFIO中使用Rust,我们没有那种自由。这就是事实,我改变不了。"他还说,如果能够证明回移植问题得到解决,他对Rust在VFIO中的反对就会降低一些。也许,他说,可以编写一个用Rust编写的最小核心驱动程序作为C版本的替代,并使用它来了解回移植问题到底有多困难。

关于回移植,Greg Kroah-Hartman建议Gunthorpe"不要基于任何与今天的上游内核开发无关的古老商业内核做设计决策"。如果公司希望在企业内核中获得vGPU支持,他说,他们应该支付将必要补丁回移植到这些内核中的费用。Gunthorpe回答说,在内核社区决定Rust支持不再是实验性的之前,他还没有准备好接受任何这样的依赖。他还表达了希望这个问题会自己消失的愿望:

这个论点太早了。我深切地希望我们永远不必真正去讨论它,到Nova合并进来的时候,Rust在上游已经100%准备就绪,不会有任何问题。拜托了?那能实现吗? 最终,这次对话只是渐渐消失了。从短期来看,目前没有需要做出任何决定;vGPU在当前主线内核中能正常工作的唯一方式就是使用nouveau,因此如果它以这种形式被合并,这将是非常令人惊讶的。即使Nova的开发者也没有反对这一点。从长远来看,希望事情会像Gunthorpe希望的那样进展,当Nova准备好进入上游时,相应的行动路径也会很明确。

也许生活不会那么简单,但总体来说还是有理由保持乐观。虽然双方的立场似乎都很绝对,但所有参与的开发人员都表现出寻找对所有人都有效的解决方案的兴趣。他们对社区正在努力实现的长期目标没有分歧,也有理由相信最终会达成一致。

不过,这次讨论中提出的一些主题可能会再次出现。任何依赖于Rust代码的功能都将是一个挑战,要回移植到古老的企业内核,所以合并这些代码可能会遭到反对,即使来自那些支持Rust的开发者。如果Rust项目要取得成功,内核总有一天必须做出这种转变。不过,人们可以期待会有进一步的讨论,关于何时应该达到这一转变点。