[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZKvQPAN9OkS3dZ4d@infradead.org>
Date: Mon, 10 Jul 2023 02:32:44 -0700
From: Christoph Hellwig <hch@...radead.org>
To: Ming Lei <ming.lei@...hat.com>
Cc: Christoph Hellwig <hch@...radead.org>,
Damien Le Moal <dlemoal@...nel.org>,
Andreas Hindborg <nmi@...aspace.dk>,
open list <linux-kernel@...r.kernel.org>,
"open list:BLOCK LAYER" <linux-block@...r.kernel.org>,
Andreas Hindborg <a.hindborg@...sung.com>,
Minwoo Im <minwoo.im.dev@...il.com>,
Matias Bjorling <Matias.Bjorling@....com>,
gost.dev@...sung.com, Jens Axboe <axboe@...nel.dk>,
Aravind Ramesh <Aravind.Ramesh@....com>,
Johannes Thumshirn <jth@...nel.org>,
Hans Holmberg <Hans.Holmberg@....com>
Subject: Re: [PATCH v6 1/3] ublk: add opcode offsets for DRV_IN/DRV_OUT
On Mon, Jul 10, 2023 at 05:27:23PM +0800, Ming Lei wrote:
> Yes, that is exactly what we are doing.
>
> The added macros of UBLK_IO_OP_DRV_IN_START[END] are just for supporting
> more ublk passthrough commands, and the motivation is for running
> check(such as buffer direction) in two sides easily.
>
> However, I think it is just fine to delay to add it until introducing
> the 2nd ublk pt command.
The concept of a passthrough command just doesn't make sense for an
on the wire protocol. It is a linux concept that distinguished between
the Linux synthetic command like REQ_OP_READ/WRITE/DISCARD etc that are
well defined and can be used by file systems and other consumers, and
ways to pass through arbitrary blobs only known by the driver.
Anything in a wire protocol needs to be very well defined in that
protocol completely indpendent of what Linux concept it maps to.
Especially as the Linux concepts can change, and fairly frequently do.
Powered by blists - more mailing lists