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.
--
Pavel Begunkov
