On Tue, Feb 19, 2019 at 01:47:36PM -0800, John Stultz wrote: > On Tue, Feb 19, 2019 at 1:13 PM Laura Abbott <labb...@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 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
