From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932634AbdJKG1T (ORCPT ); Wed, 11 Oct 2017 02:27:19 -0400 Received: from mx1.redhat.com ([209.132.183.28]:44612 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932573AbdJKG1S (ORCPT ); Wed, 11 Oct 2017 02:27:18 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 1BF3FC047B6B Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=kraxel@redhat.com Message-ID: <1507703234.31518.5.camel@redhat.com> Subject: Re: [PATCH v15 5/7] vfio: ABI for mdev display dma-buf operation From: Gerd Hoffmann To: Alex Williamson , "Zhang, Tina" Cc: "chris@chris-wilson.co.uk" , "zhenyuw@linux.intel.com" , "Lv, Zhiyuan" , "Wang, Zhi A" , "Tian, Kevin" , "daniel@ffwll.ch" , "kwankhede@nvidia.com" , "intel-gfx@lists.freedesktop.org" , "intel-gvt-dev@lists.freedesktop.org" , "linux-kernel@vger.kernel.org" , Daniel Vetter Date: Wed, 11 Oct 2017 08:27:14 +0200 In-Reply-To: <20171010201824.25d2ae79@t450s.home> References: <1507629007-3183-1-git-send-email-tina.zhang@intel.com> <1507629007-3183-6-git-send-email-tina.zhang@intel.com> <20171010131645.4846e9dd@t450s.home> <237F54289DF84E4997F34151298ABEBC7C5EE7B4@SHSMSX101.ccr.corp.intel.com> <20171010201824.25d2ae79@t450s.home> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Wed, 11 Oct 2017 06:27:18 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, > No, the parameter wouldn't be a char, you'd use an __u32 for the > dmabuf_id.  I'm just referencing the structure of the GET_DEVICE_FD > as > an ioctl which returns an fd through the return value and takes a > single parameter.  I don't mean to imply matching the type of that > parameter. >   Gerd, what are your thoughts on that, it'd make it slightly > easier to call GET_GFX_DMABUF, but it limits us to file descriptor > for > the dmabuf whereas with a flag and expandable structure we could use > some future mechanism to return the dmabuf to userspace. It's fine with me. The point of using fd's to refer to dmabufs is that they can be passed around easily, so I doubt this is going to change. cheers, Gerd