Inquiry Versioning

Gerry.Houlder at seagate.com Gerry.Houlder at seagate.com
Thu Apr 3 07:00:44 PDT 2008


* From the T10 Reflector (t10 at t10.org), posted by:
* Gerry.Houlder at seagate.com
*
Many products do report an older version number than they have actually
implemented because many systems (especially consumer systems) still have
older driver or other software that doesn't understand the newer version
numbers and may refuse to work with products that report the newer version
number. This is common with the OEM version of many products (which is sold
for general use, therefore could be used in older, not updated, or even
home brew computers). This reduces the rate in which products are returned
because "they didn't work" even though there is nothing wrong with the
product.
 By contrast, products shipped with firmware customized for particular
customers have to meet specific procurement specs. These usually stay up to
date with the version numbers, but sometimes even these specs require older
version numbers at the same time as requiring implementation of new
features.
This behavior is justified by the definition of "reserved" in SPC-x and
other T10 standards:
reserved: A keyword referring to bits, bytes, words, fields and code values
that are set aside for future standardization. A reserved bit, byte, word
or field shall be set to zero, or in accordance with a future extension to
this standard.
The wording that a reserved bit, byte or feature can be implemented "in
accordance with a future extension of this standard" is broadly interpreted
to allow products with older version number to implement newer features.
Older driver software will typically do not attempt to use the new features
anyway, so this is not believed to cause a backward compatibility issues.
It helps greatly, however, when newer HBA hardware is installed which can
use newer features (e.g., higher transfer rate) but is still being used
with the same old driver software that insists on seeing the older version
number in order to install the target device.
	     "Mike Berhan"						   
	     <mikeb at bustrace.c						   
	     om>							To 
	     Sent by:		       <t10 at t10.org>			   
	     owner-t10 at t10.org						cc 
	     No Phone Info						   
	     Available						   Subject 
				       Inquiry Versioning		   
	     04/02/2008 04:33						   
	     PM 							   
* From the T10 Reflector (t10 at t10.org), posted by:
* "Mike Berhan" <mikeb at bustrace.com>
*
The 8-bit "Version" field in the standard Inquiry data (offset 2) is
defined
as:
"The VERSION field indicates the implemented version of this standard and
is
defined in table XXX"
I have an SPC-3 compliant device I am evaluating.  In reviewing SPC-3 (or
4), a value of 05h would indicate compliance with SPC-3.  However, this
device returns 03h (SPC).
Now if you look down in the Version Descriptors, this device does return
support for Version Descriptor 0300h (SPC-3).
Either the 03h was left in the "Version" field for backwards compatibility
issues, or it's just a firmware bug.
My question for this forum is this.  Does a device that claims SPC-3
compatibility violate the rules of the specification if the Inquiry version
states it's an SPC-1 device.  Or, does the fact that it claims SPC-3
support
in the Version Descriptors allow such a device to pass.
I realize that this is a rather esoteric point.  However, it is of interest
to me as I spend time flagging these issues as firmware bugs and I want to
know if this device violates any SPC-3 versioning requirements.  Any
thoughts appreciated.
-------
Mike Berhan
busTRACE Technologies
9700 Village Center Drive
Suite 50-F
Granite Bay, CA  95746
916.773.4554 phone
916.218.6283 fax
http://www.bustrace.com
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org
*
* 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