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

[Maxime Ripard]

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

Attachment: signature.asc
Description: PGP signature