Re: [RFC 0/6] scsi: scsi transport for ufs devices

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]

  Powered by Linux