Subject: extending Rsoc complicates bootstrap
Date: Thu, 25 Jan 2007 09:37:31 -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: 7517
Formatted message: HTML-formatted message

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@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