Hi Lyude, thanks a lot for working on this! :) > On 29 Aug 2025, at 19:35, Lyude Paul <[email protected]> wrote: > > Now that my rust skills have been honed, I noticed that there's a lot of > generics in our gem bindings that don't actually need to be here. Currently > the hierarchy of traits in our gem bindings looks like this: > > * Drivers implement: > * BaseDriverObject<T: DriverObject> (has the callbacks) > * DriverObject (has the drm::Driver type) > * Crate implements: > * IntoGEMObject for Object<T> where T: DriverObject > Handles conversion to/from raw object pointers > * BaseObject for T where T: IntoGEMObject > Provides methods common to all gem interfaces > > Also of note, this leaves us with two different drm::Driver associated > types: > * DriverObject::Driver > * IntoGEMObject::Driver > > I'm not entirely sure of the original intent here unfortunately (if anyone > is, please let me know!), but my guess is that the idea would be that some > objects can implement IntoGEMObject using a different ::Driver than > DriverObject - presumably to enable the usage of gem objects from different > drivers. A reasonable usecase of course. > > However - if I'm not mistaken, I don't think that this is actually how > things would go in practice. Driver implementations are of course > implemented by their associated drivers, and generally drivers are not > linked to each-other when building the kernel. Which is to say that even in > a situation where we would theoretically deal with gem objects from another > driver, we still wouldn't have access to its drm::driver::Driver > implementation. It's more likely we would simply want a variant of gem > objects in such a situation that have no association with a > drm::driver::Driver type. > > Taking that into consideration, we can assume the following: > * Anything that implements BaseDriverObject will implement DriverObject > In other words, all BaseDriverObjects indirectly have an associated > ::Driver type - so the two traits can be combined into one with no > generics. > * Not everything that implements IntoGEMObject will have an associated > ::Driver, and that's OK. > > And with this, we now can do quite a bit of cleanup with the use of > generics here. As such, this commit: > > * Removes the generics on BaseDriverObject > * Moves DriverObject::Driver into BaseDriverObject > * Removes DriverObject > * Removes IntoGEMObject::Driver > * Add AllocImpl::Driver, which we can use as a binding to figure out the > correct File type for BaseObject > > Leaving us with a simpler trait hierarchy that now looks like this: > > * Drivers implement: BaseDriverObject > * Crate implements: > * IntoGEMObject for Object<T> where T: DriverObject > * BaseObject for T where T: IntoGEMObject > > Which makes the code a lot easier to understand and build on :). > > Signed-off-by: Lyude Paul <[email protected]> > > --- > V2: > * Don't refer to Object<T> in callbacks, as this would result in drivers > getting the wrong gem object type for shmem gem objects once we add > support for those. Instead, we'll just add a type alias to clean this > part up. > V3: > * Fix nova compilation > * Also, add an associated driver type to AllocImpl - as we still need the > current driver accessible from BaseObject so that we can use the driver's > various associated types, like File > V4:
? This is v3. Can you clarify this before we go further? :) > * Add missing Object = Self constraint to type bounds for create_handle, > lookup_handle. I forgot that if drivers can have private gem objects with > a different data layout, we can only guarantee gem objects with handles > are of the same gem object type as the main one in use by the driver. > > Signed-off-by: Lyude Paul <[email protected]> — Daniel
