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

[Laura Abbott]

On 2/19/19 1:30 PM, Andrew F. Davis wrote:
> 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.
> 

I think we just fundamentally disagree here. I don't see keeping
legacy users as slowing anything down. We're still getting
the new ABI that we actually like and we get the chance to easily
go back and test. Having a non broken ABI makes it much
easier to do testing and validation and comparison. We can remove
the last ABI before we move it out of staging.

Thanks,
Laura

> Andrew
> 
>> Thanks,
>> Laura