On Wed, Sep 25, 2024 at 11:08:40AM +1000, Dave Airlie wrote: > On Wed, 25 Sept 2024 at 10:53, Jason Gunthorpe <jgg@xxxxxxxxxx> wrote: > > > > On Tue, Sep 24, 2024 at 09:56:58PM +0200, Danilo Krummrich wrote: > > > > > Currently - and please correct me if I'm wrong - you make it sound to me as if > > > you're not willing to respect the decisions that have been taken by Nouveau and > > > DRM maintainers. > > > > I've never said anything about your work, go do Nova, have fun. > > > > I'm just not agreeing to being forced into taking Rust dependencies in > > VFIO because Nova is participating in the Rust Experiment. > > > > I think the reasonable answer is to accept some code duplication, or > > try to consolidate around a small C core. I understad this is > > different than you may have planned so far for Nova, but all projects > > are subject to community feedback, especially when faced with new > > requirements. > > > > I think this discussion is getting a little overheated, there is lots > > of space here for everyone to do their things. Let's not get too > > excited. > > How do you intend to solve the stable ABI problem caused by the GSP firmware? > > If you haven't got an answer to that, that is reasonable, you can talk > about VFIO and DRM and who is in charge all you like, but it doesn't > matter. I suggest the same answer everyone else building HW in the kernel operates under. You get to update your driver with your new HW once per generation. Not once per FW release, once per generation. That is a similar level of burden to maintain as most drivers. It is not as good as the excellence Mellanox does (no SW change for a new HW generation), but it is still good. I would apply this logic to Nova as well, no reason to be supporting random ABI changes coming out every month(s). > Fundamentally the problem is the unstable API exposure isn't something > you can build a castle on top of, the nova idea is to use rust to > solve a fundamental problem with the NVIDIA driver design process > forces on us (vfio included), I firmly believe you can't solve a stable ABI problem with language features in an OS. The ABI is totally unstable, it will change semantically, the order and nature of functions you need will change. New HW will need new behaviors and semantics. Language support can certainly handle the mindless churn that ideally shouldn't even be happening in the first place. The way you solve this is at the root, in the FW. Don't churn everything. I'm a big believer and supporter of the Mellanox super-stable approach that has really proven how valuable this concept is to everyone. So I agree with you, the extreme unstableness is not OK in upstream, it needs to slow down a lot to be acceptable. I don't necessarily agree to Mellanox like gold standard as the bar, but certainly must be way better than it is now. FWIW when I discussed the VFIO patches I was given some impression there would not be high levels of ABI churn on the VFIO side, and that there was awareness and understanding of this issue on Zhi's side. Jason
