On Mon, 4 Nov 2019 at 20:24, Brian Starkey <Brian.Starkey@xxxxxxx> wrote: > > Hi John, > > On Fri, Nov 01, 2019 at 09:42:34PM +0000, John Stultz wrote: > > From: "Andrew F. Davis" <afd@xxxxxx> > > > > 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. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
