On Tue, Feb 19, 2019 at 1:46 PM Laura Abbott <labb...@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 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel