linux-kernel - Re: [RFC v3 03/33] rust: drm/kms: Introduce the main ModeConfigObject traits

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] [day] [month] [year] [list]

Message-ID: <20250314-friendly-hilarious-axolotl-ccf19e@houat>
Date: Fri, 14 Mar 2025 11:44:52 +0100
From: Maxime Ripard <mripard@...nel.org>
To: Lyude Paul <lyude@...hat.com>
Cc: dri-devel@...ts.freedesktop.org, rust-for-linux@...r.kernel.org, 
	Danilo Krummrich <dakr@...nel.org>, mcanal@...lia.com, Alice Ryhl <aliceryhl@...gle.com>, 
	Simona Vetter <sima@...ll.ch>, Daniel Almeida <daniel.almeida@...labora.com>, 
	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 <benno.lossin@...ton.me>, 
	Andreas Hindborg <a.hindborg@...nel.org>, Trevor Gross <tmgross@...ch.edu>, 
	open list <linux-kernel@...r.kernel.org>
Subject: Re: [RFC v3 03/33] rust: drm/kms: Introduce the main
 ModeConfigObject traits

On Wed, Mar 05, 2025 at 05:59:19PM -0500, Lyude Paul wrote:
> The KMS API has a very consistent idea of a "mode config object", which
> includes any object with a drm_mode_object struct embedded in it. These
> objects have their own object IDs which DRM exposes to userspace, and we
> introduce the ModeConfigObject trait to represent any object matching these
> characteristics.
> 
> One slightly less consistent trait of these objects however: some mode
> objects have a reference count, while others don't. Since rust requires
> that we are able to define the lifetime of an object up-front, we introduce
> two other super-traits of ModeConfigObject for this:

I'm not entirely sure what you mean by that, sorry. Would you have a
small example of the challenge that forced you to split it into two
separate traits?

> * StaticModeObject - this trait represents any mode object which does not
>   have a reference count of its own. Such objects can be considered to
>   share the lifetime of their parent KMS device

I think that part is true for both cases. I'm not aware of any
reference-counted object that might outlive the DRM device. Do you have
an example?

> * RcModeObject - this trait represents any mode object which does have its
>   own reference count. Objects implementing this trait get a free blanket
>   implementation of AlwaysRefCounted, and as such can be used with the ARef
>   container without us having to implement AlwaysRefCounted for each
>   individual mode object.
> 
> This will be able to handle most lifetimes we'll need with one exception:
> it's entirely possible a driver may want to hold a "owned" reference to a
> static mode object.

I guess it kind of derives from the conversation above, but would you
have an example of a driver wanting to have a reference to a mode object
that isn't on the same lifetime than the DRM device?

Maxime

Download attachment "signature.asc" of type "application/pgp-signature" (274 bytes)