linux-kernel - Re: [PATCH v3 01/14] rust: drm: gem: Simplify use of generics

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <C036DE82-747A-4DCE-845F-CE832DA8991A@collabora.com>
Date: Mon, 1 Sep 2025 12:37:10 -0300
From: Daniel Almeida <daniel.almeida@...labora.com>
To: Lyude Paul <lyude@...hat.com>
Cc: dri-devel@...ts.freedesktop.org,
 rust-for-linux@...r.kernel.org,
 linux-kernel@...r.kernel.org,
 Danilo Krummrich <dakr@...nel.org>,
 Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
 Maxime Ripard <mripard@...nel.org>,
 Thomas Zimmermann <tzimmermann@...e.de>,
 David Airlie <airlied@...il.com>,
 Simona Vetter <simona@...ll.ch>,
 Miguel Ojeda <ojeda@...nel.org>,
 Alex Gaynor <alex.gaynor@...il.com>,
 Boqun Feng <boqun.feng@...il.com>,
 Gary Guo <gary@...yguo.net>,
 Björn Roy Baron <bjorn3_gh@...tonmail.com>,
 Benno Lossin <lossin@...nel.org>,
 Andreas Hindborg <a.hindborg@...nel.org>,
 Alice Ryhl <aliceryhl@...gle.com>,
 Trevor Gross <tmgross@...ch.edu>,
 Asahi Lina <lina+kernel@...hilina.net>,
 "open list:DRM DRIVER FOR NVIDIA GPUS [RUST]" <nouveau@...ts.freedesktop.org>
Subject: Re: [PATCH v3 01/14] rust: drm: gem: Simplify use of generics

Hi Lyude, thanks a lot for working on this! :)

> On 29 Aug 2025, at 19:35, Lyude Paul <lyude@...hat.com> 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@...hat.com>
> 
> ---
> 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 <lyude@...hat.com>

— Daniel