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@chromium.org wrote:
On Wed, Nov 26, 2014 at 4:19 PM, Rob Clark robdclark@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