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

[John Stultz]

On Wed, Feb 20, 2019 at 7:07 AM Brian Starkey <Brian.Starkey at arm.com> wrote:
>
> 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`

Hrm. I'm a bit hesitant on that, as that enshrines a naming convention as abi.

Also I personally don't think the heap-types are particularly well
defined. The memory itself is either contiguous or not, 32bit dma
accessible or not, etc. -  the specific implementation "type"
[system-contig, carveout, chunk, cma] isn't as useful from userland
other then conventions of how the heaps may be partitioned between
users.

So I'm probably happier to hide that detail.  If someone wants to do
dynamic heap discovery, we probably need a proper constraint solution.

For now, a potential generic gralloc would just have to have some
device specific policy file that defines which heap device to use for
which type of allocation it wants. Not completely unlike an fstab.

thanks
-john