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. 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
