On Thu, Sep 17, 2020 at 6:39 PM Jason Gunthorpe <jgg@xxxxxxxx> wrote: > > On Thu, Sep 17, 2020 at 06:06:14PM +0200, Christian König wrote: > > > > If it is already taking a page fault I'm not sure the extra function > > > > call indirection is going to be a big deal. Having a uniform VMA > > > > sounds saner than every driver custom rolling something. > > > > > > > > When I unwound a similar mess in RDMA all the custom VMA stuff in the > > > > drivers turned out to be generally buggy, at least. > > > > > > > > Is vma->vm_file->private_data universally a dma_buf pointer at least? > > > Nope. I think if you want this without some large scale rewrite of a > > > lot of code we'd need a vmops->get_dmabuf or similar. Not pretty, but > > > would get the job done. > > > > Yeah, agree that sounds like the simplest approach. > > I don't think that will fly, it is clearly only papering over a mess > inside DRM/dma buf :\ dma-buf started out as something to paper over the disjoint mess of allocators, since it was pretty clear to anyone involved we're not going to unify them anytime soon, if ever. So the mess pretty much is bound to stay. I think most reasonable thing would be to throw a common vmops in there somehow, but even that means some large scale surgery across every driver/subsystem involved in dma-buf. It wouldn't unify anything, all it would give you is a constant vma->vm_ops to do some kind of upcasting. And that would still only give you a slightly less opaque pointer with a callback to upcast to a dma-buf in some driver/subsystem specific way. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
