From: "Andreas Hindborg (Samsung)" <nmi@metaspace.dk>
To: Christoph Hellwig <hch@infradead.org>
Cc: Ming Lei <ming.lei@redhat.com>,
Damien Le Moal <dlemoal@kernel.org>,
open list <linux-kernel@vger.kernel.org>,
"open list:BLOCK LAYER" <linux-block@vger.kernel.org>,
Minwoo Im <minwoo.im.dev@gmail.com>,
Matias Bjorling <Matias.Bjorling@wdc.com>,
gost.dev@samsung.com, Jens Axboe <axboe@kernel.dk>,
Aravind Ramesh <Aravind.Ramesh@wdc.com>,
Johannes Thumshirn <jth@kernel.org>,
Hans Holmberg <Hans.Holmberg@wdc.com>
Subject: Re: [PATCH v6 1/3] ublk: add opcode offsets for DRV_IN/DRV_OUT
Date: Tue, 11 Jul 2023 08:23:40 +0200 [thread overview]
Message-ID: <87a5w3ymff.fsf@metaspace.dk> (raw)
In-Reply-To: <ZKvQPAN9OkS3dZ4d@infradead.org>
Christoph Hellwig <hch@infradead.org> writes:
> 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.
Yet most on-the-wire protocols for actual hardware does support this
some way or another. But I agree that for ublk it is probably not
needed. It would probably be easier to talk to the ublk daemon through
other means than passthrough in the block layer.
>
> 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.
I somewhat agree in the sense that for consistency, we should either
move zone management commands to the DRV_OUT range OR move report_zones
out of this special range and just next to the zone management
operations. I like the latter option better, and I would love to see the
block layer do the same at some point. It feels backwards that
report_zones get special treatment all over the place.
Best regards,
Andreas
next prev parent reply other threads:[~2023-07-11 6:47 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-06 13:09 [PATCH v6 0/3] ublk: enable zoned storage support Andreas Hindborg
2023-07-06 13:09 ` [PATCH v6 1/3] ublk: add opcode offsets for DRV_IN/DRV_OUT Andreas Hindborg
2023-07-06 23:50 ` Damien Le Moal
2023-07-07 0:59 ` Ming Lei
2023-07-07 1:42 ` Damien Le Moal
2023-07-10 6:52 ` Christoph Hellwig
2023-07-10 9:27 ` Ming Lei
2023-07-10 9:32 ` Christoph Hellwig
2023-07-10 10:02 ` Ming Lei
2023-07-11 6:23 ` Andreas Hindborg (Samsung) [this message]
2023-07-11 8:22 ` Christoph Hellwig
2023-07-11 9:02 ` Andreas Hindborg (Samsung)
2023-07-11 9:27 ` Christoph Hellwig
2023-07-11 10:15 ` Andreas Hindborg (Samsung)
2023-07-11 12:01 ` Christoph Hellwig
2023-07-06 13:09 ` [PATCH v6 2/3] ublk: add helper to check if device supports user copy Andreas Hindborg
2023-07-06 23:50 ` Damien Le Moal
2023-07-07 1:02 ` Ming Lei
2023-07-06 13:09 ` [PATCH v6 3/3] ublk: enable zoned storage support Andreas Hindborg
2023-07-07 0:19 ` Damien Le Moal
2023-07-07 6:53 ` Andreas Hindborg (Samsung)
2023-07-07 10:59 ` Ming Lei
2023-07-07 15:04 ` Andreas Hindborg (Samsung)
2023-07-08 14:11 ` Ming Lei
2023-07-10 6:07 ` Andreas Hindborg (Samsung)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87a5w3ymff.fsf@metaspace.dk \
--to=nmi@metaspace.dk \
--cc=Aravind.Ramesh@wdc.com \
--cc=Hans.Holmberg@wdc.com \
--cc=Matias.Bjorling@wdc.com \
--cc=axboe@kernel.dk \
--cc=dlemoal@kernel.org \
--cc=gost.dev@samsung.com \
--cc=hch@infradead.org \
--cc=jth@kernel.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ming.lei@redhat.com \
--cc=minwoo.im.dev@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.