Bob,
Yes to me the Cdb Usage mask distinctions
between a reserved bit, an always zero bit, and an always one bit remain unclear.
Just suppose …
Yesterday, the spec defined only 00b and
01b and 10b. We mass-produced those devices. Today the spec changes. We tell
some idiot compiler only that the device shall interpret 000b and 001b and 010b.
We unconsciously end up mass-producing devices that actually discard the top
bit of the field and thus again actually distinguish only 00b and 01b and 10b.
In this way, we change our intent from yesterday to today, but we actually
produce the same device design twice. Still at T10 our intent is to say that
the correct Rsoc description of these devices does differ. Merely because we
had more bits in mind as we made today’s device, now mask x07 is its correct
self-description, whereas mask x03 was the correct self-description of
yesterday’s physically identical device.
So far so good?
Then, whether mask x03 or mask x07 is
correct for any actual device is not a testable specification – it’s
merely a matter of unobservable intent – the mask is a kind of pointer to
a particular part of the spec found in one revision or another. As device
people, we encode that pointer as the list of bits defined in the part of that spec
that we bothered to read, that’s all.
Is this a correct interpretation?
Funny but true? I’m not trying to
be dense – this is where I arrive logically, courtesy my vast ignorance.
Yes I see now, our unelaborated text as it stands arguably contradicts
itself. Until you helped me pause and focus, I wasn’t clear on this
question – and if you object in reply, then I’ve still got it
wrong!
To clarify the text, we could try to talk
more often of fields, less often of bits, e.g.:
"If the device server evaluates a bit
in the CDB for the command being queried, the usage map shall contain a one in
the corresponding bit position. If any bit representing part of a field is
returned as one, all bits for the field shall be returned as one. If the device
server ignores or treats as reserved a [+field] [-bit] in the CDB for the
command being queried, the usage map shall contain a zero in [+all] the
corresponding bit position[+s]."
The difficulty of fields growing over time
might also be worth inserting a sentence, e.g.:
“When the device server complies
with two or more specifications that disagree over how many or which bits are all
the bits of the field, then the usage map shall match only the specification
that takes precedence.”
Hope this helps,
From: Sheffield,
Robert L [mailto:robert.l.sheffield@intel.com]
Sent: Tuesday, January 23, 2007 8:29
PM
To: Pat LaVarre; T10 Reflector
Subject: RE: mask x07 or x03
defines Rsoc Cdb byte 2
Wish I could
provide an answer, but all I can do is pose two more follow-on questions:
I notice that
while the REPORTING OPTIONS field (lower 3 bits of byte-2 in the REPORT
SUPPORTED OPERATION CODES command) is a 3-bit field, the there are only 3 code
values defined for this field (000b, 001b, and 010b - bit-2 is always zero),
with code values 011b - 111b reserved. The rules say,
"If the device server evaluates a bit in the CDB for the command being queried, the usage map shall contain a one in the corresponding bit position. If any bit representing part of a field is returned as one, all bits for the field shall be returned as one. If the device server ignores or treats as reserved a bit in the CDB for the command being queried, the usage map shall contain a zero in the corresponding bit position."
The first sentence says report three bits worth of "1". If one could interpret the fact that the reserved code values cover all the values where the high-order bit is set to 1, that the high order bit is therefore reserved, then the rule in the second sentence might lead to setting only the lower-order two bits to "1", and the high-order bit to zero. But I don't think that's the intent, so I think you are correct, 7h is correct.
The other more
interesting question is why isn't byte-2 equal to 87h (rather than 07h). Does
this mean that the device server in the example treats the RCTD bit as
reserved? Are device servers that support the REPORT SUPPORTED OPERATION CODES
command required to support an RCTD bit set to one? If not, then presumably the
device server could report either 07h or 87h in byte-2 of the CDB usage map for
the REPORT SUPOPRTED OPERATION CODES CDB.
Either way -
looks like something to fix in SPC-4.
Bob Sheffield
From:
owner-t10@t10.org [mailto:owner-t10@t10.org] On
Behalf Of Pat LaVarre
Sent: Tuesday, January 23, 2007
5:16 PM
To: T10 Reflector
Subject: mask x07 or x03 defines
Rsoc Cdb byte 2
* From the T10 Reflector (t10@t10.org), posted by: * "Pat
LaVarre"
Spc4r08.pdf
at p.231 discusses "REPORT SUPPORTED OPERATION CODES". It has
an example CDB usage map that labeled as "the" CDB usage map of
"REPORT SUPPORTED OPERATION CODES".
A3h, 0Ch, 03h, FFh, FFh, FFh, FFh, FFh, FFh, FFh, 00h, 07h is the example.
A3h, 0Ch, 07h, FFh, FFh, FFh, FFh, FFh, FFh, FFh, 00h, 07h is what I expected
at first glance, since the REPORTING OPTION codes go in the three lsb's of byte
2 of the Cdb, and my mask 07h rather than the Pdf's 03h in byte 2 would be a
mask of three lsb's rather than two lsb's.
Is 07h rather than 03h in byte 2 yes obviously what we meant to type, or have I
misunderstood, or is something interesting happening here?
Curiously yours,
* * For T10 Reflector information, send a message with * 'info t10' (no
quotes) in the message body to majordomo@t10.org