Re: [PATCH v4 1/3] rust: drm: gem: Simplify use of generics

[Danilo Krummrich <dakr@kernel.org>]

On 9/8/25 8:46 PM, Lyude Paul 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 <lyude@redhat.com>
> Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com>

Acked-by: Danilo Krummrich <dakr@kernel.org>