[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <1507703234.31518.5.camel@redhat.com>
Date: Wed, 11 Oct 2017 08:27:14 +0200
From: Gerd Hoffmann <kraxel@...hat.com>
To: Alex Williamson <alex.williamson@...hat.com>,
"Zhang, Tina" <tina.zhang@...el.com>
Cc: "chris@...is-wilson.co.uk" <chris@...is-wilson.co.uk>,
"zhenyuw@...ux.intel.com" <zhenyuw@...ux.intel.com>,
"Lv, Zhiyuan" <zhiyuan.lv@...el.com>,
"Wang, Zhi A" <zhi.a.wang@...el.com>,
"Tian, Kevin" <kevin.tian@...el.com>,
"daniel@...ll.ch" <daniel@...ll.ch>,
"kwankhede@...dia.com" <kwankhede@...dia.com>,
"intel-gfx@...ts.freedesktop.org" <intel-gfx@...ts.freedesktop.org>,
"intel-gvt-dev@...ts.freedesktop.org"
<intel-gvt-dev@...ts.freedesktop.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Daniel Vetter <daniel.vetter@...ll.ch>
Subject: Re: [PATCH v15 5/7] vfio: ABI for mdev display dma-buf operation
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
Powered by blists - more mailing lists