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.
otherwise all the attaching is done by the driver behind callbacks. Switching it to some memfd could be pretty simple. But The main thing it'd need to share is iterator handling like forwarding in the block layer, and it should be fine as it's already passed as a completely opaque object with no knowledge about pages / dma / etc. for the middle layers.
But none of that really sits in the current lib/ code anyway?
lib/ is most certainly the wrong place for something that absolutely is not library functionality but directly interacts with a few subsystems.
It only interacts with dma-buf, and even for dma-buf attachments are created by the driver. Block, nvme, io_uring are users, either using the helpers or implementing callbacks.
Ok. Let's assume for the argument's sake it's not dma-buf specific, if not lib/, where would you put it? I was also assuming that dma-buf being under drivers/ is rather a relic of the past rather than the desired location, hmm?
drivers/dma-buf is a pretty natural place for it, I could not thing where else you'd place dma-buffers. I'm not sure how hmm has anything to do with it.
-- Pavel Begunkov
---end quoted text---