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

[John Stultz]

On Tue, Feb 19, 2019 at 1:46 PM Laura Abbott <labbott at redhat.com> wrote:
>
> On 2/19/19 1:39 PM, Andrew F. Davis wrote:
> > On 2/19/19 3:13 PM, Laura Abbott 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 :(
> >>
> >
> > Most likely there will never be a one-size-fits-all solution here. So
> > allowing for an extensible ABI that permits new information to be
> > exported as needed will be important.
> >
> >> 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?
> >>
> >
> > We can always add more ioctls, we cant go back and remove the old ones
> > if we make them too clunky and have to remove something they expose. A
> > simple starting ABI seems to make the most sense here. Even heap type
> > doesn't look like a good thing to expose, it is just as static and
> > one-off as heap name, I don't see it having all that much use :/
> >
>
> That's my point though, why are we adding this ioctl now if we
> don't have a good idea of its use case or why we want the heap
> type exposed? If we come up with a good use later we can
> add the ioctl then with better requirements.

Ok. I think we three are in agreement here.  Best to drop this bit and
leave it till someone has a clear need/use.

thanks
-john