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 <labb...@redhat.com>
Cc: Sumit Semwal <sumit.sem...@linaro.org>
Cc: Liam Mark <lm...@codeaurora.org>
Cc: Brian Starkey <brian.star...@arm.com>
Cc: Andrew F. Davis <a...@ti.com>
Cc: Alistair Strachan <astrac...@google.com>
Cc: dri-devel@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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
