Transparent Scsi, redefined accurately now in retrospect

plavarre at lexar.com plavarre at lexar.com
Mon Aug 13 21:18:14 PDT 2007


* From the T10 Reflector (t10 at t10.org), posted by:
* <plavarre at lexar.com>
*
> The USB documentation also provides no guidance
> beyond the term "transparent SCSI" for implementation;
Aye, omitted on purpose.
Me Pat LaVarre I omitted that definition in 1998/1999, by better to be
clearly undisclosed and published than measurably wrong or late.
> this would upgrade it
> ...
> T10 USB Study Group scheduled for Wednesday 19-Sep-2007 from 12:30 to
1:30
> (the intent is to fit into the end of the CAP WG lunch break, with
minimal meeting overlap).
Best wishes to this dream. Six relevant memories might help:
--- 1. I remember counting exactly ten resets defined for Scsi Thru Usb,
last I tried.
The ten Scsi Thru Usb resets were the nine resets shared with any other
Usb Class implemented as a Usb Interface, and then one more reset of its
own. The one class-specific reset was the Usb Control Pipe request "Bulk
Only Mass Storage Reset" (Bomsr).
I've never seen anyone try to map those ten Scsi thru Usb to ten Sam
resets. I do remember people arguing over which Scsi reset of Sam, if
any, corresponds to the Bomsr.
Me, I always thought of Bomsr as a reset of all logical units, a reset
with enough force to provoke x 6 29 = Sk Asc, in units that implement
unit attentions. I hear people since have disagreed over what Bomsr
means, e.g., maybe Bomsr means just one unit if it arrives between
Command Out and Status In phase, while Bomsr means all units if Bomsr
arrives at other times.
--- 2. I remember thinking a correct Transparent Scsi definition for Spc
op x12 Inquiry nowadays appears separately in the Usb 'bootability'
material.
That material helped bring Usb's binary-code-only mass-storage test into
existence. That doc might also have got Spc op x03 Request Sense right,
I'm not sure. Probably not much more than that, that committee also ran
out of time.
Jan Axelson's Usb Mass Storage text might dig a little into all this
too.
--- 3. I remember we spoke of 'transparency' in part to say that Scsi op
x12 Inquiry is the right way for the host to discover things like the
Scsi PeripheralDeviceType (Pdt).
Some docs of Usb bizarrely suggested that the host fetch some redundant
re-encoded Usb copy of that info in the Usb bInterfaceSubClass code.
Merely by being redundant and differently encoded by a whole 'nother
standards body, that info inherently could conflict with the Scsi
claims. Yeeuck.
So we invented code x06 to mean no-Scsi-info-here-in-Usb,
please-go-to-Scsi, i.e., what bInterfaceSubClass code x00 would have
meant if I had arrived on the scene early enough. That kind of
please-go-further-in transparency is the idea where the word
'transparent' came from. I hear people have shipped bInterfaceSubClass
code x00 and bInterfaceSubClass code xFF without clear definitions,
since.
--- 4. I'm not sure how significantly many Scsi Thru Usb hosts actually
interpret the bInterfaceSubClass codes.
Msft Whdc docs how Windows interprets x 06 05 02 there.
I hear Windows Vista and 2.6 Linux are matched on branching always on
all three of the Usb 'Compatible Id' bytes bInterfaceClass SubClass
Protocol.
Apple and boot/resume Bios and other Usb hosts I hear less talk of. I
suppose all hosts should branch on all three bytes always, just to talk
like Windows and Linux do.
The original idea for 'Transparent Scsi' was to simultaneously
accommodate the Microsoft tradition of Spc op x12 Inquiry for x24 (36)
first and also the Apple tradition of Spc op x00 Test Unit Ready first
and also the Linux tradition of Spc op x12 Inquiry for xFF (255) first
and so on and so on and so on. 'Be liberal in what you accept', 'be
conservative in what you send', thus actually interoperate well.
The last comment I wrote for code x06 there was something like "Apple/
Linux/ Microsoft/ Sun Scsi". The Usb committee thought "Transparent
Scsi" was a better choice of words. Personally, I missed the meeting
that changed the label on this hex, we were too busy then shipping
product.
--- 5. I remember I also spoke of 'transparency' to get permission from
our customers to ship the bastardisation of Sff with T10 Scsi that
actually commanded significant Windows peripheral market share at the
time.
That is, I needed to avoid compliance people telling me that I was
violating T10 Scsi by conforming to Sff Scsi.
That design element of merging Sff with T10 was broken as designed by
the people paying for the design work, I didn't want that element
rejected late in compliance.
I hear that T10 & Sff people have since done work to reconcile the
binary incompatible definitions of the Dbd bit in the Mode Sense Cdb
that in particular were giving us the most severe headaches at the time.
At the time, we were faced with the paradox of Sff saying device shall
receive 1 no matter what the host sends, and T10 saying host should send
1, may send 0, device shall receive 1 or 0. My compromise in the device
at the time was to follow Sff rules for op x5A Mode Sense (10) and
follow T10 rules for op x1A Mode Sense (6). I hear the Sff rules have
changed since, either to match T10 wholly or the binary-compatible
choice of saying host shall send 1, so the device may receive 1 from Sff
or 1 and 0 from T10.
I actually wrote and tested a compile-time option into the firmware in
the hope of Sff correcting their incompatibility, but Sff didn't publish
their corrections in time for us to ship that option enabled.
I hear that by now many devices since have implemented the T10 rules
exclusively, so maybe now in 2007 we really can get away with pretending
that the 1998 'Transparent SCSI' rules really were the 2007 T10 rules.
--- 6. I think I know what code x06 meant in the beginning because I
personally remember inventing Usb bInterfaceSubClass Code x06 for
Transparent Scsi, along with Usb bInterfaceProtocol code 'P' for its
usual Bbb transport.
We froze the corresponding first-article mass-produced device firmware
in autumn 1998, always I forget exactly which day. Anybody with a
sufficiently ancient wall-powered Usb Zip 100 drive could find out our
American mm/dd/yy dates. That first drive at Scsi Inquiry data offsets
32 thru 39 had "01.U09/24/98" or "01.U10/15/98" in it, I forget which.
The one date was the firmware frozen, the other the hardware, I think we
did get the firmware out first on that project. The follow-on firmware
designs had some other ProductRevisionLevel, not "01.U" at offset 32. I
don't think those designs had the Easter Egg of a string message when
Spc op x3C Read Buffer precedes Spc op x3B Write Buffer.
What code x06 means today, that's your question opened here -- a much
tougher question.
Hope this helps, good fun to see people again tilting at this old
windmill,
P.S. Would be goodness to allot a Usb Class-Specific Interface Extension
Descriptor -- the Usb analogue to version codes in Spc Inquiry -- to
achieve absolute perfect compatibility with the established x 08 06 50
codes while yet also accepting Cdb's from the host of more than x10
bytes each. If T10 Scsi offers a definition, Usb might be willing to
allot the code, Msc at usb.org might have some advice to offer.
P.P.S. Likewise would be good to compatibly announce that a particular
device actually would accept kicking up thruput by queueing Command Out
with Data Out, and Data In with Status In, and even the next Command Out
in parallel with Status In. Last I checked, the hosts tended to
conservatively wait for ack of Command Out before sending Data Out, and
to conservatively wait for ack of Data In before sending Status In, and
for compliance to wait for ack of Status In before sending the next
Command Out.
P.P.P.S. I hear that not everyone accepts that the Control byte, i.e.,
the last byte of the Cdb, always should be 00h in Scsi Thru Usb.
P.P.P.P.S. My brain dump you triggered ends about here. Hope this helps,
Happy Monday,
________________________________
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Curtis
Stevens
Sent: Monday, August 13, 2007 6:12 PM
To: T10 at t10.org
Subject: USB Study Group
There is a T10 USB Study Group scheduled for Wednesday 19-Sep-2007 from
12:30 to 1:30 (the intent is to fit into the end of the CAP WG lunch
break, with minimal meeting overlap).  The purpose of this meeting is to
explore the interest in developing a new USB queuing protocol for Mass
Storage devices.  The USB documentation also provides no guidance beyond
the term "transparent SCSI" for implementation; this would upgrade it
into a full SCSI Architecture Model compliant transport protocol.  The
following items need to be addressed:
1.	Requirements for using USB subclass 06h (transparent SCSI)
2.	Queuing (including task management)
3.	Autosense
4.	Encapsulate all CDBs  including the variable length ones (e.g.,
to support the Object Storage Device (OSD) command set)
5.	SAM-4 compliance
6.	 Increased transport efficiency.
Rob Elliott (HP) and Curtis Stevens (WD)
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org



More information about the T10 mailing list