Re: [PATCH v3 05/10] lib: add dmabuf token infrastructure

[Christoph Hellwig <hch@lst.de>]

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---