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.
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?
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.
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
_If_ there is no dma mappings, drivers/dma-buf would definitely be an awkward spot. Just trying to understand your criteria for placement, let's say of a generic buffer registration code assuming there is no dma-buf involved at all. Again, just a hypothetical.
where else you'd place dma-buffers. I'm not sure how hmm has anything to do with it.
Looks there is some confusion. It's was meant as an interjection with an open question, I didn't mention the HMM subsystem.