> -----Original Message----- > From: linux-scsi-owner@xxxxxxxxxxxxxxx <linux-scsi-owner@xxxxxxxxxxxxxxx> > On Behalf Of Douglas Gilbert > Sent: Monday, July 30, 2018 9:53 PM > To: Hannes Reinecke <hare@xxxxxxxx>; Bart Van Assche > <Bart.VanAssche@xxxxxxx>; hch@xxxxxx; jejb@xxxxxxxxxxxxxxxxxx; linux- > scsi@xxxxxxxxxxxxxxx; jthumshirn@xxxxxxx; martin.petersen@xxxxxxxxxx; > Avri Altman <Avri.Altman@xxxxxxx> > Cc: Vinayak Holikatti <Vinayak.Holikatti@xxxxxxx>; Avi Shchislowski > <Avi.Shchislowski@xxxxxxx>; Alex Lemberg <Alex.Lemberg@xxxxxxx>; > Stanislav Nijnikov <Stanislav.Nijnikov@xxxxxxx>; subhashj@xxxxxxxxxxxxxx > 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
