On 02/07/2018 05:32 PM, Laura Abbott wrote: > On 02/07/2018 07:10 AM, Alexey Skidanov wrote: >> >> >> On 02/07/2018 04:58 PM, Laura Abbott wrote: >>> On 02/06/2018 11:05 PM, Alexey Skidanov wrote: >>>> >>>> >>>>> Yup, you've hit upon a key problem. Having fallbacks be stable >>>>> was always a problem and the recommendation these days is to >>>>> not rely on them. You can specify a heap at a time and fallback >>>>> manually if you want that behavior. >>>>> >>>>> If you have a proposal to make fallbacks work reliably without >>>>> overly complicating the ABI I'm happy to review it. >>>>> >>>>> Thanks, >>>>> Laura >>>>> >>>> I think it's possible to "automate" the "manual fallback" behavior. But >>>> the real issues is using heap id to specify the particular heap object. >>>> >>>> Current API (allocation IOCTL) requires to specify the particular heap >>>> object by using heap id. From the other hand, the user space doesn't >>>> control the heaps creation order and heap id assignment. So it may be >>>> tricky, especially when more than one object of the same heap type is >>>> created automatically. >>>> >>>> Thanks, >>>> Alexey >>>> >>>> >>> >>> The query ioctl is designed to get the heap ID information without >>> needing to rely on the linking order or anything else defined in >>> the kernel. >>> >>> Thanks, >>> Laura >> >> That is true. But if we have 2 *automatically created* heaps of the same >> type, how userspace can distinguish between them? >> >> Thanks, >> Alexey >> > > The query ioctl also gives the name which should be different > for each heap. It's not ideal but the name/heap type are the best > way to differentiate between heaps without resorting to hard > coding. > > Thanks, > Laura You are correct ... It will work (assuming that user space developer knows where to look for the name :) ) So, the userspace may pass the list of pairs [heap type, name] (as part of allocation ioctl) defining the fallback order. Thanks, Alexey _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
