On 2/25/19 9:53 PM, Sumit Semwal wrote:
On Mon, 25 Feb 2019 at 20:06, Andrew F. Davis afd@ti.com wrote:
This framework allows a unified userspace interface for dma-buf exporters, allowing userland to allocate specific types of memory for use in dma-buf sharing.
Each heap is given its own device node, which a user can allocate a dma-buf fd from using the DMA_HEAP_IOC_ALLOC.
Signed-off-by: Andrew F. Davis afd@ti.com
Hello all,
I had a little less time over the weekend than I thought I would to clean this up more and finish the first set of user heaps, but wanted to get this out anyway.
ION in its current form assumes a lot about the memory it exports and these assumptions lead to restrictions on the full range of operations dma-buf's can produce. Due to this if we are to add this as an extension of the core dma-buf then it should only be the user-space advertisement and allocation front-end. All dma-buf exporting and operation need to be placed in the control of the exporting heap. The core becomes rather small, just a few hundred lines you see here. This is not to say we should not provide helpers to make the heap exporters more simple, but they should only be helpers and not enforced by the core framework.
As an idea, I really like the direction for this. It gives a good amount of flexibilty for exporters. So definitely thanks to John and you for taking the plunge there :)
Basic use model here is an exporter (dedicated heap memory driver, CMA, System, etc.) registers with the framework by providing a struct dma_heap_info which gives us the needed info to export this heap to userspace as a device node. Next a user will request an allocation, the IOCTL is parsed and the request made to a heap provided alloc() op. The heap should return the filled out struct dma_heap_buffer, including exporting the buffer as a dma-buf. This dma-buf we then return to the user as a fd. Buffer free is still a bit open as we need to update some stats and free some memory, but the release operation is controlled by the heap exporter, so some hook will have to be created.
It all needs a bit more work, and I'm sure I'll find missing parts when I add some more heaps, but hopefully this framework is simple enough that it does not impede the implementation of all functionality once provided by ION (shrinker, delayed free), nor any new functionality needed for future heap exporting devices.
Other than current heaps, the secure heaps have been talked about quite a bit in the past, so I will check with Linaro's security group on them trying out the next version as well.
As I also moonlight as a Linaro member engineer as part of SWG (andrew.davis@linaro.org) I've talked with Joakim and Etienne about the secure (unmapped) heaps, adding those are already baked into my plans here :)
Andrew
We also would need to do a performance comparison, so that's another activity to be added.
Thanks, Andrew
Best, Sumit.