SPC Inquiry for Quad-Aligned Zero -- deprecated since SPC-4 maybe

plavarre at lexar.com plavarre at lexar.com
Thu Dec 13 12:50:54 PST 2007

* From the T10 Reflector (t10 at t10.org), posted by:
* <plavarre at lexar.com>
> > http://t10.org/ftp/t10/drafts/spc4/spc4r11.pdf
> > should be should be
Thanks for pointing out that SPC-4 editing error. I didn't see it when I
copy-pasted into here.
Adobe Reader here finds the string "should be should be" only at that
place in all of that 2007 May 14 R11 draft.
Is SPC-4 still new enough we can fix such tupographical errors, or is
this an SPC-5 fix?
> Those are just ...
As for the additional gift of this substantive reply, ouch as yet I'm
missing something sorry.
The tone was disagreement, but all the detail is agreement, so far as I
can see?
So I'll try to explain again, but I'll take care to cite "shall"s, not
only the "should"s, to give a more complete picture ...
> > > http://t10.org/ftp/t10/drafts/spc4/spc4r11.pdf
> > > 4.3 CDB ... 4.3.4 Common CDB fields ... Allocation length
> > > ...
> > > An allocation length of zero specifies
> > > that no data shall be transferred.
> > > This condition shall not be considered as an error.
That's the "shall" that Rob found.
> > http://t10.org/ftp/t10/drafts/spc4/spc4r11.pdf
> > 6.4 INQUIRY command ...
> >
> > the allocation length should be should be at least four, so that ...
> > ... parameter data ... is returned.
That's our "should".
> > Do we actually now mean to be so explicitly deprecating the SCSI
> > tradition of SPC Inquiry for zero?
I trust we agree, yes we actually have explicitly deprecated a tradition
whenever, alongside a device "shall" implement, we also publish a host
"should not" send.
So far so good for citing duplicate context that we definitely hold in
> > SPC Inquiry for Quad-Aligned Zero ...
> > "12 00 00 00 00 00" ... six byte hex CDB ...
That popular test command plainly violates this "should".
The two bytes at offset three are zero, thus the Allocation Length is
zero, thus the Allocation Length is not "at least four", thus that
command plainly is a command that the host "should not" send.
> Those are just "should" not "shall" rules,
> so zero doesn't violate them.
Whoa. Do we agree here also now? I'd say both yes and no.
I'm thinking this zero does violate the "should" rules and does not
violate the "shall" rules.
I'm thinking this zero thus moves this host into the "should not"
category, without giving permission to the device to become a "shall
not" device.
I think that's unfortunate -- accidental -- not what we mean -- like
typing "should be should be" to mean "should be".
Tell me yes and I'll propose corrected language. Tell me No and I'll
learn something essential and new.
> The sentences explain why the advice is provided
> a value less than 4 or 5 results in a truncated LENGTH field, which
could be misinterpreted.
Furthermore, a value of zero results in an entirely absent EVPD 0
Additional Length or EVPD 1 Page Length field, which is even more likely
to be misunderstood, especially by hosts that neglect our should rule of
zero the data buffer before executing any non-time-critical command to
copy data into the buffer. (Not that I have the least clue where we hide
that rule in SAM either.)
> The general ALLOCATION LENGTH field definition in
> (used by most but not all commands that have a field with that name)
> specifically says zero is not an error.
> INQUIRY uses the definition.
This is more context for our "shall". I agree.
Spc4r11.pdf 14 May 2007 6.4 "INQUIRY command" cites yes.
Mmc6r01.pdf 24 October 2007 6.8 "INQUIRY command" cites SPC-3. Close
Those are all the current competing redefinitions of INQUIRY published
by T10.org known to me.
> > where our 
> > language is that recommends SPC Inquiry Allocation Lengths be 
> > quad-aligned for SCSI transports that require quad-aligned data 
> > phases?
> The SCSI Architecture Model requires SCSI transports to support byte
precision for transfer lengths.
De jure, that's the theory we publish at T10.org, ok.
De facto, massively many instances of hosts and devices actually don't
follow that rule. I've got war stories in SPI, in SCSI thru ATA (ATAPI),
in FireWire. For FireWire I remember seeing Apple & Microsoft coordinate
to define a new FireWire descriptor to say hey this device implements
all of SBP-2 Normative Annex B except not that part of SAM.
Not good for my Windows storage peripheral industry to have the theory
flat wrong so massively often.
> The wording in SAM-4 revision 13b section is:
> "All SCSI transport protocol standards shall define support
> for a resolution of one byte for the Application Client Buffer Size
Thank you! I hadn't found that. Now I know what to cite when I complain
of this mob rule in particular.
> It allows transports to ensure
> that interim transfers are aligned on larger boundaries,
> as long as the last transfer can deliver any specific number of bytes:
> "SCSI transport protocol standards may define restrictions
> on the resolution of the Application Client Buffer Offset argument.
Ah. Next question if I may:
For transports that share memory addresses between host and device --
such as FireWire -- does this sentence allow the device to require the
host to align its memory address, or vice versa?
> SCSI transport protocol standards may define restrictions
> on the resolution of the Request Byte Count argument
> for any call to Send Data-In or any call to Receive Data-Out
> that does not transfer the last byte of the Application Client
Aye, crystal clear, I thank you again.
I see this is the same theory as the ATAPI claim that any number of
bytes can cross the bus two bytes at a time, with maybe an odd byte at
the end. Works great any time both host and device bother to support it.
> ...
Most curiously yours, thanks again,
* 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