[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAD=HUj7h1d8dXG94FUtj4fmeUvUM0dm6NW8WHGZAceHae0zGLw@mail.gmail.com>
Date: Wed, 26 Feb 2020 12:56:58 +0900
From: David Stevens <stevensd@...omium.org>
To: Gerd Hoffmann <kraxel@...hat.com>
Cc: David Airlie <airlied@...ux.ie>, Daniel Vetter <daniel@...ll.ch>,
"Michael S . Tsirkin" <mst@...hat.com>,
Jason Wang <jasowang@...hat.com>,
Sumit Semwal <sumit.semwal@...aro.org>,
linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org,
virtualization@...ts.linux-foundation.org,
Linux Media Mailing List <linux-media@...r.kernel.org>,
linaro-mm-sig@...ts.linaro.org, virtio-dev@...ts.oasis-open.org
Subject: Re: [virtio-dev] Re: [PATCH 1/2] virtio: add dma-buf support for
exported objects
On Tue, Feb 25, 2020 at 3:10 PM Gerd Hoffmann <kraxel@...hat.com> wrote:
>
> On Wed, Feb 19, 2020 at 05:06:36PM +0900, David Stevens wrote:
> > This change adds a new flavor of dma-bufs that can be used by virtio
> > drivers to share exported objects. A virtio dma-buf can be queried by
> > virtio drivers to obtain the UUID which identifies the underlying
> > exported object.
>
> That duplicates a bunch of code from dma-buf.c in virtio_dma_buf.c.
>
> How about dma_buf_{get,set}_uuid, simliar to dma_buf_set_name?
While I'm not opposed to such an API, I'm also hesitant to make
changes to the dma-buf API for a single use case.
As for the duplicated code around virtio_dma_buf_export_info, it can
be removed by sacrificing a little bit of type safety, if that's
preferable.
-David
Powered by blists - more mailing lists