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
signature.asc
Description: PGP signature
