Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <20191101214238.78015-1-john.stultz@linaro.org>
 <20191101214238.78015-2-john.stultz@linaro.org> <20191104102410.66wlyoln5ahlgkem@DESKTOP-E1NTVVP.localdomain>
In-Reply-To: <20191104102410.66wlyoln5ahlgkem@DESKTOP-E1NTVVP.localdomain>
From:   Dave Airlie <airlied@gmail.com>
Date:   Tue, 5 Nov 2019 02:58:17 +1000
Message-ID: <CAPM=9tydXxV-6++HkkA+JX9GPWE1sN_8CGVCVn-Mwfgfzcn=hg@mail.gmail.com>
Subject: Re: [PATCH v14 1/5] dma-buf: Add dma-buf heaps framework
To:     Brian Starkey <Brian.Starkey@arm.com>
Cc:     John Stultz <john.stultz@linaro.org>,
        lkml <linux-kernel@vger.kernel.org>,
        "Andrew F. Davis" <afd@ti.com>, Laura Abbott <labbott@redhat.com>,
        Benjamin Gaignard <benjamin.gaignard@linaro.org>,
        Sumit Semwal <sumit.semwal@linaro.org>,
        Liam Mark <lmark@codeaurora.org>,
        Pratik Patel <pratikp@codeaurora.org>,
        Vincent Donnefort <Vincent.Donnefort@arm.com>,
        Sudipto Paul <Sudipto.Paul@arm.com>,
        Christoph Hellwig <hch@infradead.org>,
        Chenbo Feng <fengc@google.com>,
        Alistair Strachan <astrachan@google.com>,
        Hridya Valsaraju <hridya@google.com>,
        Sandeep Patil <sspatil@google.com>,
        Hillf Danton <hdanton@sina.com>,
        "dri-devel@lists.freedesktop.org" <dri-devel@lists.freedesktop.org>,
        nd <nd@arm.com>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Mon, 4 Nov 2019 at 20:24, Brian Starkey <Brian.Starkey@arm.com> wrote:
>
> Hi John,
>
> On Fri, Nov 01, 2019 at 09:42:34PM +0000, John Stultz wrote:
> > From: "Andrew F. Davis" <afd@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.