> > Well, no, I am calling a core driver to be the very minimal parts that > are actually shared between vfio and drm. It should definitely not > include key parts you want to work on in rust, like the command > marshaling. Unfortunately not, the fw ABI is the unsolved problem, rust is our best solution. > > I expect there is more work to do in order to make this kind of split, > but this is what I'm thinking/expecting. > > > > But the whole point of Nova is to replace the NVKM parts of Nouveau, since > > > that's where the problems we want to solve reside in. > > > > Just to re-emphasise for Jason who might not be as across this stuff, > > > > NVKM replacement with rust is the main reason for the nova project, > > 100% the driving force for nova is the unstable NVIDIA firmware API. > > The ability to use rust proc-macros to hide the NVIDIA instability > > instead of trying to do it in C by either generators or abusing C > > macros (which I don't think are sufficient). > > I would not include any of this in the very core most driver. My > thinking is informed by what we've done in RDMA, particularly mlx5 > which has a pretty thin PCI driver and each of the drivers stacked on > top form their own command buffers directly. The PCI driver primarily > just does some device bootup, command execution and interrupts because > those are all shared by the subsystem drivers. > > We have a lot of experiance now building these kinds of > multi-subsystem structures and this pattern works very well. > > So, broadly, build your rust proc macros on the DRM Nova driver and > call a core function to submit a command buffer to the device and get > back a response. > > VFIO will make it's command buffers with C and call the same core > function. > > > I think the idea of a nova drm and nova core driver architecture is > > acceptable to most of us, but long term trying to main a nouveau based > > nvkm is definitely not acceptable due to the unstable firmware APIs. > > ? nova core, meaning nova rust, meaning vfio depends on rust, doesn't > seem acceptable ? We need to keep rust isolated to DRM for the > foreseeable future. Just need to find a separation that can do that. That isn't going to happen, if we start with that as the default positioning it won't get us very far. The core has to be rust, because NVIDIA has an unstable firmware API. The unstable firmware API isn't some command marshalling, it's deep down into the depths of it, like memory sizing requirements, base message queue layout and encoding, firmware init procedures. These are all changeable at any time with no regard for upstream development, so upstream development needs to be insulated from these as much as possible. Using rust provides that insulation layer. The unstable ABI isn't a solvable problem in the short term, using rust is the maintainable answer. Now there are maybe some on/off ramps we can use here that might provide some solutions to bridge the gap. Using rust in the kernel has various levels, which we currently tie into one place, but if we consider different longer term progressions it might be possible to start with some rust that is easier to backport than other rust might be etc. Strategies for moving nvkm core from C to rust in steps, or along a sliding scale of fws supported could be open for discussion. The end result though is to have nova core and nova drm in rust, that is the decision upstream made 6-12 months ago, I don't see any of the initial reasons for using rust have been invalidated or removed that warrant revisiting that decision. Dave.
