Read Disc Structure - Format Code FFh - Structure length ambiguity
mikeb at bustrace.com
Thu Jan 31 11:02:36 PST 2008
Formatted message: <A HREF="r0801311_f.htm">HTML-formatted message</A>
Attachment #1: <A HREF="r0801311_image001.png">image001.png</A>
Attachment #2: <A HREF="r0801311_image002.png">image002.png</A>
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.
9700 Village Center Drive
Granite Bay, CA 95746
More information about the T10