Subject: Rsoc descriptions vary merely by intent maybe Date: Thu, 25 Jan 2007 09:57:47 -0800 From: "Pat LaVarre" <plavarre@lexar.com> To: "Sheffield, Robert L" <robert.l.sheffield@intel.com> Cc: "T10 Reflector" <t10@t10.org> X-Message-Number: 7518 Formatted message: HTML-formatted message 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