[EARLY RFC][PATCH 3/4] ion: Add HEAP_INFO ioctl to be able to fetch heap type

John Stultz john.stultz at linaro.org
Tue Feb 19 21:47:36 UTC 2019


On Tue, Feb 19, 2019 at 1:13 PM Laura Abbott <labbott at redhat.com> wrote:
>
> On 2/15/19 12:24 PM, John Stultz wrote:
> > The per-device heaps don't support HEAP_QUERY ioctl, since
> > the name is provided in the devnode path and the heapid isn't
> > useful with the new interface (one uses the fd of heapdevice).
> >
> > But, one missing bit of functionality is a way to find the
> > heap type. So provide a HEAP_INFO ioctl which exposes the
> > heap type out so there is the potential for some sort of
> > dynamic heap matching/discovery.
> >
> > Most likely this IOCTL will be useful when extended to allow
> > some sort of opaque constraint bitfield to be shared so userland
> > can match heaps with devices in a fully dynamic way.
> >
>
> We've been waiting on the constraint solving for a while and
> it's never really happened :(
>

Yea. I'm not trying to open that up again.

> It certainly works but I'm concerned about adding this and
> then finding (yet again) that it doesn't work. We're
> getting the heap name now but do we lose anything if we
> don't expose it as part of the ABI?

Right. So all we're exporting in this patch is the heap_type. This was
somewhat of an afterthought for me, as practically, I suspect the
gralloc users of ion will know which heap they want by name, and won't
do any sort of dynamic heap finding.

That said, ion's current API provides the QUERY interface which gives
you a list of heap ids/names/types, so if you wanted something that on
any random system was able to find a ION_HEAP_TYPE_DMA heap and use
it, you could.

So this HEAP_INFO ioctl provides a way to do the same. That's it.

That said, I could envision the ioctl to be extended (via the reserved
values) to provide some sort of constraint cookie to allow for
constraint solving, but that's still a unsolved issue at large.

Given the handwaving at the constraints part, and that the heap type
is a pretty coarse grained enum (only 6 types, as of now - one being
catchall "custom"), I'm fine holding off on this bit unless folks
really see it as valuable.

thanks
-john


More information about the dri-devel mailing list