[EARLY RFC][PATCH 0/4] ION per heap devices
Laura Abbott
labbott at redhat.com
Tue Feb 19 21:54:52 UTC 2019
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
More information about the dri-devel
mailing list