> -----Original Message-----
> From: linux-scsi-ow...@vger.kernel.org <linux-scsi-ow...@vger.kernel.org>
> On Behalf Of Douglas Gilbert
> Sent: Monday, July 30, 2018 9:53 PM
> To: Hannes Reinecke <h...@suse.com>; Bart Van Assche
> <bart.vanass...@wdc.com>; h...@lst.de; j...@linux.vnet.ibm.com; linux-
> s...@vger.kernel.org; jthumsh...@suse.de; martin.peter...@oracle.com;
> Avri Altman <avri.alt...@wdc.com>
> Cc: Vinayak Holikatti <vinayak.holika...@wdc.com>; Avi Shchislowski
> <avi.shchislow...@wdc.com>; Alex Lemberg <alex.lemb...@wdc.com>;
> Stanislav Nijnikov <stanislav.nijni...@wdc.com>; subha...@codeaurora.org
> Subject: Re: [RFC 0/6] scsi: scsi transport for ufs devices
>
> On 2018-07-30 02:13 PM, Hannes Reinecke wrote:
> > On 07/30/2018 08:01 PM, Bart Van Assche wrote:
> >> On Sun, 2018-07-29 at 16:33 +0300, Avri Altman wrote:
> >>> Here is a proposal to use the scsi transport subsystem to manage
> >>> ufs devices.
> >>>
> >>> scsi transport is a framework that allow to send scsi commands to
> >>> a non-scsi devices. Still, it is flexible enough to allow
> >>> sending non-scsi commands as well. We will use this framework to
> >>> manage ufs devices by sending UPIU transactions.
> >>>
> >>> We added a new scsi transport module, a ufs-bsg LLD companion,
> >>> and some new API to the ufs driver.
> >>
> >> My understanding is that all upstream code uses the bsg interface for
> *SCSI*
> >> commands. Sending UPIU commands over a bsg interface seems like
> abuse of that
> >> interface to me. Aren't you opening a can of worms with such an
> approach?
> >>
> > I beg to disagree.
> >
> > bsg was precisely designed to handle non-SCSI commands, as this was the
> main
> > limitation of the original 'sg' interface.
> > The original intention was to allow sending of transport frames for the
> various
> > SCSI transports (like FC or SAS), but there is no direct requirement for
> > bsg to
> > be limited to SCSI.
> > Quite the contrary.
>
> I designed 'struct sg_io_v4' found in include/uapi/linux/bsg.h to handle
> storage
> related protocols, not just the SCSI command set. After the guard, the next
> two fields in that structure are:
> __u32 protocol; /* [i] 0 -> SCSI , .... */
> __u32 subprotocol; /* [i] 0 -> SCSI command, 1 -> SCSI task
> management function, .... */
>
> So there is lots of room for other protocols. Also the naming of fields is in
> terms of request, response, data-in and data-out rather than SCSI command
> specific terms (e.g. SCSI sense data maps to the response, while the SCSI
> status is returned via a layered error mechanism). It also handles bidi data
> transfers (which the sg_io_v3 interface does not).
>
>
> NVMe didn't exist when struct sg_io_v4 was designed. If it was then I would
> have made provisions for "metadata" transfers. One use for metadata
> transfer might be to send protection information separately (i.e. as
> metadata) rather than interleave with the user data as SCSI does. Is
> NVMe metadata much used? And the extreme case:
> bidi_data+bidi_metadata,
> any examples of that?
>
> Doug Gilbert
OK then. Let's give it a try. Will re-send it as patchset.
Thanks,
Avri
