On Wed, May 10, 2017 at 11:11 AM, Daniel Vetter <daniel@xxxxxxxx> wrote: > On Wed, May 10, 2017 at 10:20:09AM -0400, Rob Clark wrote: >> On Wed, May 10, 2017 at 9:48 AM, Sean Paul <seanpaul@xxxxxxxxxxxx> wrote: >> > On Wed, May 10, 2017 at 08:26:42AM +0200, Daniel Vetter wrote: >> >> On Tue, May 9, 2017 at 5:36 PM, Rob Clark <robdclark@xxxxxxxxx> wrote: >> >> > Disadvantages: >> >> > * depending on userspace architecture, layers left on screen could >> >> > be considered an information leak, ie. new incoming master process >> >> > has access to buffers that are still being scanned out. >> >> >> >> I'm not sure this is much of a problem really, >> > >> > Agreed. I've been under the impression that relying on pipe cleanup in rmfb is a >> > somewhat inelegant thing to do anyways. >> > >> > One bikeshed comment I have is with the name. We've moved everything from >> > *_unreference to *_put. To stay consistent with that, as well as balance out >> > GETFB, could we rename to PUTFB? >> >> In general, I'm ok w/ PUTFB as the name.. except GETFB is actually >> more like GETFBINFO (ie. it doesn't take a ref).. so calling it PUTFB >> implies it is the counterpart to GETFB when it really isn't. >> >> (I suppose technically we could rename GETFB to something else without >> breaking ABI, and since we copy the headers into libdrm it might not >> be *that* big a pita..) > > If we bikeshed the name, CLOSEFB? It is not an unreference operation, > since the drm_file fb reference is not refcounted. The underlying fb is, > but not the per-file reference (which is the thing we nuke here). > > This is similar to closing files, which will close it even if you have > piles of other references to the same fd in userspace (but the underlying > struct file in the kernel might or might not disappear). Seems more > fitting to me than either UNREF or PUT. Also fits with GEM_CLOSE on the > gem side, which works the same way (it just drops the drm_file reference, > nothing else). yeah, I like CLOSEFB BR, -R > -Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
