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

[Brian Starkey]

On Tue, Feb 19, 2019 at 01:47:36PM -0800, John Stultz wrote:
> 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.

What do people think about putting the heap type into the device name?
The whole query API is then replaced with `ls`

-Brian

> 
> thanks
> -john