From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Hellstrom Subject: Re: Pairing drm_prime_handle_from_fd with close Date: Fri, 08 Nov 2013 18:38:11 +0100 Message-ID: <527D2183.90008@vmware.com> References: <527CB6BD.4000702@vmware.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from smtp-outbound-2.vmware.com (smtp-outbound-2.vmware.com [208.91.2.13]) by gabe.freedesktop.org (Postfix) with ESMTP id 2C46B10DA1F for ; Fri, 8 Nov 2013 13:13:49 -0800 (PST) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces@lists.freedesktop.org Errors-To: dri-devel-bounces@lists.freedesktop.org To: Daniel Vetter Cc: "dri-devel@lists.freedesktop.org" List-Id: dri-devel@lists.freedesktop.org On 11/08/2013 06:19 PM, Daniel Vetter wrote: > On Fri, Nov 8, 2013 at 11:02 AM, Thomas Hellstrom wrote: >> It seems like prime_handle_from_fd needs to be paired with a GEM_CLOSE ioctl >> instead of a new generic HANDLE_CLOSE ioctl. >> >> This oversight is not really a big problem but there are two solutions: >> 1) Create a new ioctl called HANDLE_CLOSE or something similar. >> 2) Use the GEM_CLOSE ioctl, but add a driver callback for drivers that are >> not GEM-aware. >> >> It seems like GEM_CLOSE has already spread into user-space clients, so >> unless someone tell me otherwise, I'll be using >> 2) for the vmwgfx prime implementation. > Oops, I didn't really realize when fixing the prime lifetime stuff > that vmwgfx doesn't use gem handles for it's buffers. What about > 3) Move drm_gem_remove_prime_handles to drm_prime.c, expose it to > modules and use that in the vmwgfx handle close ioctl? > Imo GEM_CLOSE shouldn't ever be called by generic code in userspace, > so if that's already broken it should be fixed in userspace not > papered over in the kernel by partially faking gem on vmwgfx. I just > fear that if we start doing that we need to virtualize more of the few > gem bits, which renders the point of gem being optional moot. > -Daniel Hi! I'm afraid I don't quite follow you here.. The problem is not in the kernel, with vmwgfx we don't even need to populate the drm prime list structures. The problem is for user-space clients that have a prime fd, and call drm_prime_handle_from_fd. Since this function is pretty generic, they need a generic way to close that handle. I don't really have any preferences, except IMHO user space shouldn't need to guess what's the type of the underlying kernel object of that handle.. (This is for generic user-space using prime for buffer sharing between processes, not primarily for sharing buffers between devices). Thanks, Thomas