[RFC] drm: store property instead of id in obj attachment

[Daniel Vetter]

On Tue, Dec 02, 2014 at 02:09:41PM -0500, Rob Clark wrote:
> On Tue, Dec 2, 2014 at 1:47 PM, Sean Paul <seanpaul at chromium.org> wrote:
> > On Wed, Nov 26, 2014 at 4:19 PM, Rob Clark <robdclark at gmail.com> wrote:
> >> Keep property pointer, instead of id, in per mode-object attachments.
> >> This will simplify things in later patches.
> >>
> >> ---
> >> Does anyone care about the lifetime issue and dangling property ptrs?
> >
> > Judging by the lack of response, it seems like the answer is probably no.
> >
> > That said, it doesn't seem like a whole lot of work to add refcounting
> > to drm_property so we don't have to worry about it. Maybe I'm missing
> > something.
> 
> true.. but then the property would not actually go away then, it would
> be kept alive by the extra ref.  That said, I can't think of a valid
> reason for dynamically creating/destroying properties, so I'm tempted
> to just add a comment somewhere to explain that detaching from mode
> objects would be required if someone did want to dynamically destroy a
> property and leave it at that..

I've thought we'd implement blob properties by allowing userspace to
allocate a blob prop and then pass around it's id. Similar for
framebuffers those would need to be refcounted and also cleaned up (the
public side at least) when their owning file_priv is closed.

But in general I agree with Rob, there's not really a use case for
refcounted driver-side props that I could think of.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch