extending Rsoc complicates bootstrap

Pat LaVarre plavarre at lexar.com
Thu Jan 25 09:37:31 PST 2007


Formatted message: <A HREF="r0701251_f.htm">HTML-formatted message</A>

Bob,
I like both of these questions, yes thank you.	Likely I'll say more on
the other shortly, meanwhile:
Yes to me the REPORT SUPPORTED OPERATION CODES bootstrap is unclear.
As a host, how do I get from a device that accepts a traditional INQUIRY
(i.e., x 12 0 0 0 24 0 = Cdb, while expecting 0 to x24 data bytes in) up
to knowing I may try one or another specific variation of the REPORT
SUPPORTED OPERATION CODES command, such as this new RCTD variation?
I have no clear idea.
________________________________
From: Sheffield, Robert L [mailto:robert.l.sheffield at 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 at t10.org [mailto:owner-t10 at 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 at 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 at t10.org 



More information about the T10 mailing list