lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ