[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aTFllxgsNCzGdzKB@infradead.org>
Date: Thu, 4 Dec 2025 02:42:31 -0800
From: Christoph Hellwig <hch@...radead.org>
To: Pavel Begunkov <asml.silence@...il.com>
Cc: 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>,
Christoph Hellwig <hch@....de>, 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>,
Christian König <christian.koenig@....com>,
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 Sun, Nov 23, 2025 at 10:51:21PM +0000, Pavel Begunkov wrote:
> +static inline struct dma_token *
> +dma_token_create(struct file *file, struct dma_token_params *params)
> +{
> + struct dma_token *res;
> +
> + if (!file->f_op->dma_map)
> + return ERR_PTR(-EOPNOTSUPP);
> + res = file->f_op->dma_map(file, params);
Calling the file operation ->dmap_map feels really misleading.
create_token as in the function name is already much better, but
it really is not just dma, but dmabuf related, and that should really
be encoded in the name.
Also why not pass the dmabuf and direction directly instead of wrapping
it in the odd params struct making the whole thing hard to follow?
Powered by blists - more mailing lists