On Thu, Feb 28, 2019 at 9:21 AM Andrew F. Davis <a...@ti.com> wrote: > > On 2/27/19 3:55 PM, John Stultz wrote: > > On Wed, Feb 27, 2019 at 8:38 AM Andrew F. Davis <a...@ti.com> wrote: > >> > >> We can always add back the free op, the alternative is to have the heap > >> export the fd. > >> > >> I'm not sure either is needed though, when we > >> dma_buf_put(buffer->dmabuf) on the error path it should trigger the > >> release op, and that can cleanup the allocations in the heap. > > > > Good point, but I worry that's a bit subtle. > > > > Also doing the stuff with the helpers where we have to register a free > > callback is kind of ugly, and I personally like the symmetry of having > > free hooks if we have allocation hooks (even if the dmabuf release > > hook initiates the free call). > > > > I do like the symmetry of a free op, just not sure how or what should be > done in it that couldn't be taken care of in the dmabuf.release op..
I came around on this. I've reworked the top core allocate function to basically just return the result of heap->allocate(), which now returns the dmabuf fd. Any error handling/freeing is then kept to the heap allocate function and we don't need a heap free op. I still have to have a free callback for the helper functions, but I may do some more cleanup there. thanks -john _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
