[RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging

[Laura Abbott]

On 03/12/2017 12:05 PM, Daniel Vetter wrote:
> On Sun, Mar 12, 2017 at 2:34 PM, Benjamin Gaignard
> <benjamin.gaignard at linaro.org> wrote:
>> 2017-03-09 18:38 GMT+01:00 Laura Abbott <labbott at redhat.com>:
>>> On 03/09/2017 02:00 AM, Benjamin Gaignard wrote:
>>>> 2017-03-06 17:04 GMT+01:00 Daniel Vetter <daniel at ffwll.ch>:
>>>>> On Mon, Mar 06, 2017 at 11:58:05AM +0100, Mark Brown wrote:
>>>>>> On Mon, Mar 06, 2017 at 11:40:41AM +0100, Daniel Vetter wrote:
>>>>>>
>>>>>>> No one gave a thing about android in upstream, so Greg KH just dumped it
>>>>>>> all into staging/android/. We've discussed ION a bunch of times, recorded
>>>>>>> anything we'd like to fix in staging/android/TODO, and Laura's patch
>>>>>>> series here addresses a big chunk of that.
>>>>>>
>>>>>>> This is pretty much the same approach we (gpu folks) used to de-stage the
>>>>>>> syncpt stuff.
>>>>>>
>>>>>> Well, there's also the fact that quite a few people have issues with the
>>>>>> design (like Laurent).  It seems like a lot of them have either got more
>>>>>> comfortable with it over time, or at least not managed to come up with
>>>>>> any better ideas in the meantime.
>>>>>
>>>>> See the TODO, it has everything a really big group (look at the patch for
>>>>> the full Cc: list) figured needs to be improved at LPC 2015. We don't just
>>>>> merge stuff because merging stuff is fun :-)
>>>>>
>>>>> Laurent was even in that group ...
>>>>> -Daniel
>>>>
>>>> For me those patches are going in the right direction.
>>>>
>>>> I still have few questions:
>>>> - since alignment management has been remove from ion-core, should it
>>>> be also removed from ioctl structure ?
>>>
>>> Yes, I think I'm going to go with the suggestion to fixup the ABI
>>> so we don't need the compat layer and as part of that I'm also
>>> dropping the align argument.
>>>
>>>> - can you we ride off ion_handle (at least in userland) and only
>>>> export a dma-buf descriptor ?
>>>
>>> Yes, I think this is the right direction given we're breaking
>>> everything anyway. I was debating trying to keep the two but
>>> moving to only dma bufs is probably cleaner. The only reason
>>> I could see for keeping the handles is running out of file
>>> descriptors for dma-bufs but that seems unlikely.
>>>>
>>>> In the future how can we add new heaps ?
>>>> Some platforms have very specific memory allocation
>>>> requirements (just have a look in the number of gem custom allocator in drm)
>>>> Do you plan to add heap type/mask for each ?
>>>
>>> Yes, that was my thinking.
>>
>> My concern is about the policy to adding heaps, will you accept
>> "customs" heap per
>> platforms ? per devices ? or only generic ones ?
>> If you are too strict, we will have lot of out-of-tree heaps and if
>> you accept of of them
>> it will be a nightmare to maintain....
> 
> I think ion should expose any heap that's also directly accessible to
> devices using dma_alloc(_coherent). That should leave very few things
> left, like your SMA heap.
> 
>> Another point is how can we put secure rules (like selinux policy) on
>> heaps since all the allocations
>> go to the same device (/dev/ion) ? For example, until now, in Android
>> we have to give the same
>> access rights to all the process that use ION.
>> It will become problem when we will add secure heaps because we won't
>> be able to distinguish secure
>> processes to standard ones or set specific policy per heaps.
>> Maybe I'm wrong here but I have never see selinux policy checking an
>> ioctl field but if that
>> exist it could be a solution.
> 
> Hm, we might want to expose all the heaps as individual
> /dev/ion_$heapname nodes? Should we do this from the start, since
> we're massively revamping the uapi anyway (imo not needed, current
> state seems to work too)?
> -Daniel
> 

I thought about that. One advantage with separate /dev/ion_$heap
is that we don't have to worry about a limit of 32 possible
heaps per system (32-bit heap id allocation field). But dealing
with an ioctl seems easier than names. Userspace might be less
likely to hardcode random id numbers vs. names as well.

Thanks,
Laura