On Mon, May 18, 2026 at 11:14:09AM +0100, Pavel Begunkov wrote:
This is about dma-buf based I/O. So I'd expect it to be named dma-buf-io and no io-dmabuf, and live in drivers/dma-buf and not the unrelated lib/. But I'd like to hear from the dma-buf maintainers about that.
Looking at what Ming is saying, it'd make more sense to keep some of the parts like iterator and the file op more flexible and not automatically imply dma-buf even if it's the main and for now the only medium. I.e. ublk/fuse can use a similar interface for mapping buffers to the server even without dma mappings.
I don't know how the API should look like, maybe passing memfd, and dma-buf supports mmap, but I think it's better to call the op something like "register_buffer" instead and keep all it in lib/ for the same reasons.
Let's get the current version landed. If we come up with some kind of non-dma dmabuf in the future we can refactor it and move it around. I'm a little skeptic we'll be able to share code as long as dmabuf is allergic to physical addresses, though.
lib/ is most certainly the wrong place for something that absolutely is not library functionality but directly interacts with a few subsystems.