INVALID COMMAND OPERATION CODE
p.lavarre at IEEE.org
Fri May 16 08:45:48 PDT 2008
* From the T10 Reflector (t10 at t10.org), posted by:
* Pat LaVarre <p.lavarre at ieee.org>
> A return of INVALID COMMAND OPERATION CODE or INVALID SERVICE
> ACTION would tell the host software very specifically that the
> command is simply not supported.
> 1.) Device returns 20 00 (INVALID COMMAND OPERATION CODE)
> 2.) Device returns 24 00 (INVALID FIELD IN CDB)
> 3.) Device returns a new sense data 20 XX (INVALID SERVICE ACTION)
I agree we are discussing the developing specification for the
comparatively new idea of INVALID SERVICE ACTION.
I can share a newbie perspective on this, because it so happens that
I started writing a regression host for some of this just recently,
working to requalify myself as a T10 language lawyer, with my last
close full read of T10 texts dating back to a 1994 read focused
mainly in SCSI-2.
Me, I first thought our intent was to think of the SCSI-2 Operation
Code as having grown. That is, what was the opcode packed only into
the 8 bits of the byte at offset 0 in the CDB now has 13 bits when we
append a 5 bit ServiceAction code (as in SbcReadCapacity16) or has 24
bits when we append a 16 bit ServiceAction code (as in SbcRead32).
Indeed I see this idea directly represented visually when I read text
like "9E/10h" and "7F/0009h" in fragments like the "service action"
tables of the "Numeric order codes" Annex A of Sbc3r15.pdf. I also
see this idea visually presented in fragments like the SPC and SBC
tables of which commands create reservation conflicts: to my eye
those tables published as words are indexed in code by the wider
opcode. Indeed I was hoping to someday see our volunteers grow our
http://t10.org/lists/op-num.htm index to reflect this larger new world.
And yes, I was expecting exactly and only 20h INVALID COMMAND
OPERATION CODE whenever the device was trying to reject the whole
wide opcode, not a weird jump over to 24h INVALID FIELD IN CDB just
because some other supported opcodes happen to share some of the more
significant bits, and certainly never a 26h INVALID FIELD IN
PARAMETER LIST pointer away from the CDB into the Data Out.
A coded model that exactly matches our complete texts ends smallest,
if I start from this principle and patch just how we wittingly or
unwittingly depart from this perfect simple consistency, so far as I
know to date.
> main goal is to have this clearly defined in SPC
In passing I did notice that we'd face awkwardness in distinguishing
00h from 00/00h from 00/0000h when using programming languages
insensitive to the bit width of an integral value (as in the C
tradition). So long as we never redefine op 00h SpcTestUnitReady to
have ServiceActions, then our most significant byte will always be
nonzero, so that won't be a practical problem.
* 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