On Tue, May 19, 2026 at 08:55:32AM +0100, Pavel Begunkov wrote:
On 5/19/26 07:56, Christoph Hellwig wrote:
On Mon, May 18, 2026 at 03:23:53PM +0100, Pavel Begunkov wrote:
To be fair, it's not that dma-buf specific. This lib/ code only does some resv locking, fence waiting and queuing fences,
But all the dma resv/fence stuff is pretty tied into the dma-buf ecosystem. I don't think it would really apply to something not doing DMA at all.
The point is that those can be separated to reuse the rest.
Are you actually doing this right now? If so please share what you have, otherwise let's keep the dma-buf bits together and move things if new abstractions emerge.
But none of that really sits in the current lib/ code anyway?
It's about naming. E.g. passing a DMABUF_ITER that doesn't have a dma-buf would be confusing, and then it'll need renaming at all layers to support the use case.
Again, if you concretely are doing this right now, find a good name and place based on those abstractions. If not let's ignore it and move it if needed.
drivers/dma-buf is a pretty natural place for it, I could not thing
_If_ there is no dma mappings, drivers/dma-buf would definitely be an awkward spot.
Yes. But that's not the case right now. And from looking at the handwaiving for ublk/fuse probably not anytime soon, but maybe I'm mistaken on the latter.