[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20260107061851.GA15324@lst.de>
Date: Wed, 7 Jan 2026 07:18:51 +0100
From: Christoph Hellwig <hch@....de>
To: Pavel Begunkov <asml.silence@...il.com>
Cc: Ming Lei <ming.lei@...hat.com>, Christoph Hellwig <hch@....de>,
Christian König <christian.koenig@....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 Tue, Jan 06, 2026 at 07:51:12PM +0000, Pavel Begunkov 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.
>
> It's not an nvme specific interface, and so a file op was much more
> convenient.
It is the much better abstraction. Also the nvme subsystems is not
an actor, and registering things to the subsystems does not work.
The nvme controller is the entity that does the dma mapping, and this
interface works very well for that.
Powered by blists - more mailing lists