The Read Disc Structure – Format Code FFh CDB (MMC /
Mt. Fuji devices) allows software to retrieve the supported disc
structures. Each structure list entry is four bytes in length and looks
like this:

The “Structure Length” is defined in Mt. Fuji 7 and
MMC as:
The Structure Length field shall specify the
length of the DISC STRUCTURE data that is identified by the Format Code.
Each disc structure is preceded by a four byte header.
For example, using the above “Physical Format Information,” a
device could return:

Note that offset 0-1 shows 0802h as the “Data
Structure Length”. When you retrieve the length from the capability
list (topmost example), the drive returns 0800h. The 0802h adds two bytes
for the two additional bytes in the header (typical length scheme used in all
the t10 specifications).
Here is the problem. In the capability list, what
exactly is the “Structure Length?” I have drives from various
vendors that all handle this differently. They use one of the following
three methods. Each can argue that they meet the requirement of The
Structure Length field shall specify the length of the DISC STRUCTURE
data that is identified by the Format Code:
1.
Method #1: The drive returns the length of the
structure not including any header bytes (as you see in the above
example). For fixed length structures, this value would be two bytes less
than the value that is returned in the structure header.
2.
Method #2: The drive returns the same value as in
the structure header. In other words, the “Structure Length”
equals the “Data Structure Length”. Technically, this value
is two bytes larger than the actual disc structure (i.e. those two reserved
bytes after the Data Structure Length).
3.
Method #3: The drive returns the length of the
structure INCLUDING the four byte header. For fixed length structures,
this value would be two bytes more than what is returned in the structure
header.
While I find the specification not clear on this point, I do
believe that Method #1 is the most technically accurate (i.e. not including the
header bytes in the count).
This confusion comes from the specification leaving room for
interpretation on how to handle this (both Mt. Fuji and MMC). Katata-san,
can you clarify what was intended with the specification and also have the next
draft specification address this issue? Thank you.
-------
Mike Berhan
busTRACE Technologies
9700 Village Center Drive
Suite 50-F
Granite Bay, CA 95746
916.773.4554 phone
916.218.6283 fax
http://www.bustrace.com