INVALID COMMAND OPERATION CODE

Pat LaVarre 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.
I agree.
> options
> 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
Yes please!
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.
> ...
Regards,
*
* 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