[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aV8UJvkt7VGzHjxS@fedora>
Date: Thu, 8 Jan 2026 10:19:18 +0800
From: Ming Lei <ming.lei@...hat.com>
To: Christoph Hellwig <hch@....de>
Cc: Christian König <christian.koenig@....com>,
Pavel Begunkov <asml.silence@...il.com>,
linux-block@...r.kernel.org, io-uring@...r.kernel.org,
Vishal Verma <vishal1.verma@...el.com>, tushar.gohad@...el.com,
Keith Busch <kbusch@...nel.org>, Jens Axboe <axboe@...nel.dk>,
Sagi Grimberg <sagi@...mberg.me>,
Alexander Viro <viro@...iv.linux.org.uk>,
Christian Brauner <brauner@...nel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Sumit Semwal <sumit.semwal@...aro.org>,
linux-kernel@...r.kernel.org, linux-nvme@...ts.infradead.org,
linux-fsdevel@...r.kernel.org, linux-media@...r.kernel.org,
dri-devel@...ts.freedesktop.org, linaro-mm-sig@...ts.linaro.org
Subject: Re: [RFC v2 01/11] file: add callback for pre-mapping dmabuf
On Wed, Jan 07, 2026 at 05:01:51PM +0100, Christoph Hellwig wrote:
> On Wed, Jan 07, 2026 at 04:56:05PM +0100, Christian König wrote:
> > > But I am wondering why not make it as one subsystem interface, such as nvme
> > > ioctl, then the whole implementation can be simplified a lot. It is reasonable
> > > because subsystem is exactly the side for consuming/importing the dma-buf.
> >
> > Yeah that it might be better if it's more nvme specific came to me as well.
>
> The feature is in no way nvme specific. nvme is just the initial
> underlying driver. It makes total sense to support this for any high
> performance block device, and to pass it through file systems.
But why does FS care the dma buffer attachment? Since high performance host controller
is exactly the dma buffer attachment point.
If the callback is added in `struct file_operations` for wiring dma buffer
and the importer(host contrller), you will see it is hard to let it cross device
mapper/raid or other stackable block devices.
Thanks,
Ming
Powered by blists - more mailing lists