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@xxxxxxxxxxxx> wrote: > > On Wed, Nov 26, 2014 at 4:19 PM, Rob Clark <robdclark@xxxxxxxxx> 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
