[PATCH v14 1/5] dma-buf: Add dma-buf heaps framework

Dave Airlie airlied at gmail.com
Mon Nov 4 16:58:17 UTC 2019


On Mon, 4 Nov 2019 at 20:24, Brian Starkey <Brian.Starkey at arm.com> wrote:
>
> Hi John,
>
> On Fri, Nov 01, 2019 at 09:42:34PM +0000, John Stultz wrote:
> > From: "Andrew F. Davis" <afd at ti.com>
> >
> > This framework allows a unified userspace interface for dma-buf
> > exporters, allowing userland to allocate specific types of memory
> > for use in dma-buf sharing.
> >
> > Each heap is given its own device node, which a user can allocate
> > a dma-buf fd from using the DMA_HEAP_IOC_ALLOC.
> >
> > Additionally should the interface grow in the future, we have a
> > DMA_HEAP_IOC_GET_FEATURES ioctl which can return future feature
> > flags.
>
> The userspace patch doesn't use this - and there's no indication of
> what it's intended to allow in the future. I missed the discussion
> about it, do you have a link?
>
> I thought the preferred approach was to add the new ioctl only when we
> need it, and new userspace on old kernels will get "ENOSYS" to know
> that the kernel doesn't support it.

This works once, expand the interface 3 or 4 times with no features
ioctl, and you start being hostile to userspace, which feature does
ENOSYS mean isn't supported etc.

Next userspace starts to rely on kernel version, but then someone
backports a feature, down the rabbit hole we go.

Be nice to userspace give them a features ioctl they can use to figure
out in advance which of the 4 uapis the kernel supports.

Dave.


More information about the dri-devel mailing list