Confusion regarding vendor-unique feature pages
p.lavarre at IEEE.org
Thu Jul 22 12:58:18 PDT 2004
* From the T10 Reflector (t10 at t10.org), posted by:
* Pat LaVarre <p.lavarre at ieee.org>
> Are vendor-unique feature pages allowed to be any arbitrary length, or
> are they supposed to also be constrained to multiples of four bytes in
> length? It would be good to have confirmation of my understanding.
Me, actually, no. Vendor-specific is vendor-specific, after all. I do
Not think it's reasonable to expect vendor-specific firmware to obey
any rule not more explicitly applied to it.
I am speaking from the personal perspective of having as yet written
more device firmware than host software. Last I checked SPC, the de
facto standard requirement to align all "available length"s to ever
larger powers of two was only implicit, as a limitation compatible with
all published specifications and then massively redistributed in BCO
(binary code only) as Win 95B PATAPI PIO, as Win 98SE PATAPI DMA, etc.,
never explicit in merely public texts.
> MMC3r10g on page 318 says "All Feature descriptors shall be a multiple
> of four bytes."
> Fuji5v150 on page 264 says "All Features shall be a multiple of four
> bytes long."
"All" meaning "all now standard", or
"All" meaning "all now or ever to be made standard", or
"All" meaning "all now or ever to be standard and all vendor-specific",
I hear you like the last of those three choices.
Rumour, be it truth or slander, says much of the actual industrial
culture of Mt Fuji develops in Japanese - I don't know if Japanese
carries this same ambiguity?
> Neither document seems to suggest that this requirement may be ignored
> for vendor-unique feature pages, yet I have seen multiple drives
> recently which are reporting vendor-unique pages that are not a
> of four bytes in length.
Fascinating, thank you. Two large questions I see raised here are:
Q1) May a compliant MMC RMB device carry forward vendor-specific legacy
unchanged from other storage design traditions? Also may RMB devices
of some other PDT, such as x00 SBC, that likewise connect via PATAPI/
Q2) May each new compliant SCSI device neglect to align its available
data lengths to ever larger powers of two - eight bits in 1990, sixteen
bits in 1995, thirty-two bits in 2000, and so forth? Or will such de
facto standards as the x24 (36) byte op x12 Inquiry that begins life
halt this de facto progression, saying device alignment to thirty-two
bits is good enough for any host for ever?
Offline I remember answering, perhaps incorrectly:
Yes of course a compliant device may inherit tradition and
misalign available lengths because the host should cope, while yet an
interoperable device should not because the host might not cope.
Here specifically, I argue instead that device firmware should hide
vendor-specific features far away from the myth of useful generic SPC
tools, so as to avoid confusing consciously limited MMC hosts. For
instance, so far as I know, the legacy of a six-byte vendor-specific
page x2F does not appear in the firmware my employer shipped last April
only out of such politeness, not because I persuaded anyone that the
"feature" paragraphs of SFF/ MMC text quoted here also necessarily
require more than 16-bit alignment in the length of vendor-specific
mode pages. Indeed, in that firmware, even the vendor-specific
features designed for compelling field uses appear hidden behind
opcodes that SFF and ANSI happen to agree are vendor-specific opcodes,
again to avoid confusing any host that limits itself to merely opcodes
found standard in one place or another.
I remember I felt like I was actually losing the argument for making an
effort to hide vendor-specific features out of the way. I felt like I
was losing out to the inertial weight of internal test & manufacturing
traditions. But then an actual alpha tester sent an e-mail asking,
hey, what are these vendor-specific bits that appear mixed in with the
standard bits. That let me say, see, see, I told you, people will
notice. Please let's not encourage them and us to waste time that way.
* 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