mikeb at bustrace.com
Thu Apr 3 10:29:01 PDT 2008
* From the T10 Reflector (t10 at t10.org), posted by:
* "Mike Berhan" <mikeb at bustrace.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. <<snip>>
Completely understood and agreed.
> 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
> 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
> to allow products with older version number to implement newer features.
> Older driver software will typically do not attempt to use the new
> 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.
I am not sure if I agree that T10 standards specifically justify my example.
Since I am not talking about reserved fields, or reserved values, I think
you are referring more to a standard practice used among the developers.
If it is very common for a vendor to leave an older SPC revision level in
the "Version" field, what we are talking about is the "Version" level being
the minimum supported level and not the actual supported level. To
determine the true capabilities of the device, one must look at the version
descriptors. This seems to be the true definition of the VERSION field (as
adopted by various vendors). Would you concur with this? If so, should SPC
be adjusted to be clear on this?
I am not one to nit-pick over these types of issues as we all frequently
make trade-offs for backwards compatibility. However, I am now in that
niche of developers that helps vendors validate their devices for
SPC/MMC/SBC (etc.) compliance. It seems that a device that has a lower SPC
version in the VERSION field, than what appears in the Version Descriptors,
is a gray area with respect to validating a device for SPC compliance.
We can consider this closed from my perspective. If I detect such a device,
I will only flag it with a firmware warning instead of with a firmware bug.
If the SPC committee finds this of interest to clarify in SPC-4, that's fine
9700 Village Center Drive
Granite Bay, CA 95746
* 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