On 2/25/19 9:53 PM, Sumit Semwal wrote: > On Mon, 25 Feb 2019 at 20:06, Andrew F. Davis <a...@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 <a...@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.da...@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. >> _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
