[EARLY RFC][PATCH 0/4] ION per heap devices

Andrew F. Davis afd at ti.com
Tue Feb 19 21:30:55 UTC 2019


On 2/19/19 3:25 PM, Laura Abbott wrote:
> On 2/15/19 12:24 PM, John Stultz wrote:
>> This is a *very early RFC* (it builds, that's all I'll say :)
>> but I wanted to share it to get some initial feedback before I
>> go down the rabit hole of trying to adapt the Android userland
>> code to get this fully validated.
>>
>> This patchset tries to implement the per-heap devices for ION.
>> The main benefit is that it avoids multiplexing heap operations
>> through the /dev/ion interface, and allows for each heap to have
>> its own permissions/sepolicy rules.
>>
>> Feedback would be greatly appreciated!
>> thanks
>> -john
>>
>> Cc: Laura Abbott <labbott at redhat.com>
>> Cc: Sumit Semwal <sumit.semwal at linaro.org>
>> Cc: Liam Mark <lmark at codeaurora.org>
>> Cc: Brian Starkey <Brian.Starkey at arm.com>
>> Cc: Andrew F. Davis <afd at ti.com>
>> Cc: Alistair Strachan <astrachan at google.com>
>> Cc: dri-devel at lists.freedesktop.org
>>
>> John Stultz (4):
>>    ion: Add ION_VERSION ioctl
>>    ion: Initial hack to create per heap devices
>>    ion: Add HEAP_INFO ioctl to be able to fetch heap type
>>    ion: Make "legacy" /dev/ion support optional
>>
>>   drivers/staging/android/ion/Kconfig     |  7 +++
>>   drivers/staging/android/ion/ion-ioctl.c | 80
>> +++++++++++++++++++++++++++++++++
>>   drivers/staging/android/ion/ion.c       | 51 ++++++++++++++++-----
>>   drivers/staging/android/ion/ion.h       |  6 +++
>>   drivers/staging/android/uapi/ion.h      | 57 +++++++++++++++++++++++
>>   5 files changed, 191 insertions(+), 10 deletions(-)
>>
> 
> So it occurs to me if this is going to be a new ABI
> all together maybe we should just declare a new allocation ioctl
> to be used with it. We can keep the old ioctls around
> for legacy use cases and maybe eventually delete them
> and just use the new allocation ioctl with the new
> split heaps.
> 

Why keep the old ones, this is staging, there are no legacy users (that
matter to kernel).. Slowing progress for the sake of backwards compat
with staging just slows the de-staging down.

Andrew

> Thanks,
> Laura


More information about the dri-devel mailing list