Please send your opinions CORE Feature Hybrid disc

Takaharu Ai ai.takaharu at jp.panasonic.com
Wed Dec 28 00:32:07 PST 2005


* From the T10 Reflector (t10 at t10.org), posted by:
* Takaharu Ai <ai.takaharu at jp.panasonic.com>
*
Hello Katata-san,

>Ai san, you may have different an opinion with Editor and Henry-san.

>From your explanation, I understand that the intention of this editorial
change is to reflect the MMC definition in Mt.Fuji and some of the
commands for which MMC refers SPC are reflected from SPC, correct?

If my understanding is correct, you can treat my comment No.4, except
the followings, as just a information.

>ASC/ASCQ
>  - 3/14/00 RECORDED ENTITY NOT FOUND Write -> 8/14/00 RECORDED ENTITY
>    NOT FOUND Read
>  - We shall not define Sense Key for the ASC/ASCQ which is not
>    specified to be used for Mt.Fuji devices.


Best Regards,

Harry Ai
VEBU
Panasonic AVC Networks Company
Matsushita/Panasonic
Osaka, Japan


---------------- Start of the original message ----------------
>From: keiji_katata at post.pioneer.co.jp
>To: mtfuji5 at avc-pioneer.com
>Cc: t10 at t10.org
>Date: Wed, 28 Dec 2005 11:24:03 +0900
>Subject: Please send your opinions CORE Feature Hybrid disc
>
>
>Hi all,
>
>
>1. CORE feature V2
>
>Ai san, you may have different an opinion with Editor and Henry-san.
>
>Editorial comment:
>Thank you Ai san, Kohda san will take care those comments.
>
>Inquiry command:
>All host software uses this command to identify the device type. So regardless
>of MMC device or not, this should work. Also Mode Select, Mode Sense, all host
>software uses this command, so it is desirable that a system uses a module to
>issue this command.
>
>Read Capacity command:
>Already MMC3 (not MMC5) had this field and there was no statement. So Kohda san
>made a statement to help the host software implementation. This will reduce
>confusion of document readers.
>
>Above four command sets, we may care the document readers, so Kohda san made
>sentences. In case of other commands, they are not same situation as the above
>commands.
>
>Format unit command:
>I think this is very different situation. Because since the SBC (1997), SBC and
>Fuji were different each other. So MMC has its own description now.
>
>Read command, Write command:
>I think SBC device and MMC device have different requirements of market. So they
>must have own description.
>
>Ai san, could you consider this historical situation. Then could you reconsider
>your requests.
>
>
>2. Hybrid disc command
>
>I understand Henry-san opinion. But this has been voted and has been agreed as
>Hybrid disc command set. Posting new proposal has been closed now. And sending a
>wrong command to device is a problem of host software. In this case, it is very
>minor mistake and this should not cause any fatal problem of the end users (e.g.
>lose of data, break of media).
>
>But I would like to correct other members opinion if you can accept to change
>this issue again.
>Pioneer does not mind that device reports error, vs. device stops reporting
>error. Both case uses very similar FW program anyway.
>
>3. Request for members
>
>Please send your opinion by Jan. 8th 2006 if you may not attend MMC at Jan. 9th
>2006.
>
>Q1. CORE feature v2,
> Which do you favor Mandatory vs. Optional?
>
>Q2. Hybrid command,
> Do you accept the change of reporting error?
> If you accept, which do you favor Reporting error vs. No reporting error.
>
>Best regards,
>
>Keiji Katata
>PIONEER CORP.
>
>
>
>
>
>"Henry Gabryjelski" <Henry.Gabryjelski at microsoft.com>@avc-pioneer.com on
>2005/12/28 01:32:47
>
>mtfuji5 at avc-pioneer.com$B$KJV?.$7$F$/$@$5$$(J
>
>$BAw?.<T(J:     owner-mtfuji5 at avc-pioneer.com
>
>
>
>
>$B08 at h(J:  <mtfuji5 at avc-pioneer.com>
>cc:    <t10 at t10.org>
>bcc:
>$B7oL>(J:  RE: Fuji6 rev100 DRAFT
>
>Ai-san,
>
>I am concerned about the below suggestions for START STOP unit command
>processing as related to hybrid discs.  This method means that software
>which sends a layer change request (because previously it detected the
>logical unit supports the hybrid disc feature) cannot get an error when
>the command is a mistake.
>
>I think it is a better (and more easily tested) design to do the
>following:
>
>1) If hybrid disc feature is not _supported_ (i.e. does not exist in
>feature list), then the bits are ignored.
>2) If the hybrid disc feature is supported by the logical unit
>(regardless of current bit setting), then the bits are always confirmed
>by the logical unit.
>
>This closely matches the processing of other commands:  Since the fields
>are (in reality) not defined for logical units without the feature,
>those LU can ignore the fields.  But those LU which have the feature
>acknowledge that these bits are defined.  Therefore, they cannot ignore
>the values.  To make the change as suggested creates a one-time
>exception to how fields in command blocks are interpreted, which I think
>will cause long-term confusion.
>
>Therefore, I would like to urge that the model section 7.3 (p322) be
>modified to match the command section 17.43 (p709), in order to simplify
>command processing and ability to test the command for the host side
>also.
>
>Thanks,
>.
>
>
>-----Original Message-----
>From: owner-mtfuji5 at avc-pioneer.com
>[mailto:owner-mtfuji5 at avc-pioneer.com] On Behalf Of Takaharu Ai
>Sent: Tuesday, December 27, 2005 12:34 AM
>To: mtfuji5 at avc-pioneer.com
>Cc: t10 at t10.org
>Subject: Re: Fuji6 rev100 DRAFT
>
>Hello Kohda-san and Mt.Fuji members,
>
>We have not finished reviewing whole the document but I would like to
>inform you the current comments on Mt.Fuji6 Rev1.0 Draft
>
>
>1. ASC/ASCQ mistakes
>In the description of Format Code=21h, 22h and 23h of SEND DISC
>STRUCTURE command, Mt.Fuji requests to set ASC/ASCQ to INVALID FIELD IN
>PARAMETER LIST for the CHECK CONDITION status when the parameters have
>already been set. But in this situation, the drive returns CHECK
>CONDITION status after checking the CDB and never receive any
>parameters.
>For this type of the condition, INVALID FIELD IN CDB is the correct
>ASC/ASCQ.
>
>Same mistake is also at SEND OPC INFORMATION command on page 699.
>Mt.Fuji requests to set INVALID FIELD IN PARAMETER LIST whenParameter
>List Length field is not set to zero. But it must be INVALID FIELD IN
>CDB.
>
>
>2. Inconsistency among Hybrid disc model and its command
>In the Hybrid disc model section 7.3 on page 322, the drive behavior
>upon receiving the START STOP UNIT command to request the change of
>Format-layer is as follows;
>    If the logical unit receives this command when the Hybrid disc
>    Feature is not current, the logical unit ignores the FL bit and the
>    Destination Format-layer # field, and consequently reacts as if the
>    command was the "LOAD" command, i.e. LoEj bit set to one and Start
>    bit set to one.
>But in START STOP UNIT command section 17.43 on page 709, it is as
>follows;
>    If the Hybrid disc Feature exists but is not current and either the
>    FL bit or the Destination Format-layer # field is not set to zero,
>    the logical unit shall terminate the command with CHECK CONDITION
>    status, 5/24/00 INVALID FIELD IN CDB.
>
>In my memory, we agreed the drive behavior and its commands in October
>meeting according to my proposal explained in the distributed document
>named "Command proposal for Hybrid disc-2.pdf". It said;
>    When Hybrid Disc Feature is not current, both Layer bit and
>    Destination Format-layer # field shall be ignored.
>The name of Layer bit was changed to FL bit in November meeting.
>So, the description in the Hybrid disc model section is correct and
>17.43
>must be changed to as follows;
>    If the Hybrid disc Feature exists but is not current, both the FL
>    bit and the Destination Format-layer # field shall be ignored and
>    treated as zero.
>This is the mistake on my final proposal documents.
>
>
>3. Event class to be reported when Format-layer is changed
>In the Hybrid disc model section 7.3 on page 323, Class 3 event is
>requested to be reported in the text and in the figure. But those must
>be Class 4, Media Event.
>This is also the mistake on my proposal documents.
>
>
>4. Editorial matching with INCITS (SBC2r16, SPC3r23)
>Followings may also be necessary to be matched to INCITS documents. But
>before that, I have some questions;
>  - Why do you try to do this at this moment without any consensus of
>    Mt.Fuji members?
>  - Which documents are referred? I refer the above versions', but it is
>    only the draft, not the INCITS standards.
>
>FORMAT UNIT command
>  - LUN -> FMTPINFO bit, RTO_REQ bit and LINGLIST bit
>  - Format Code field -> DEFECT LIST FORMAT field
>  - Reserved -> Vendor specific
>  - Interleave Value -> Obsolete
>PREVENT/ALLOW MEDIUM REMOVAL command
>  - PREVENT/ALLOW MEDIUM REMOVAL command -> PREVENT ALLOW MEDIUM REMOVAL
>    command
>READ (10)/(12) command
>  - LUN (Obsolete) field -> RDPROTECT field
>  - Reserved -> FUA_NV bit
>  - RelAdr -> Obsolete
>  - Reserved -> GROUP NUMBER field
>READ CAPACITY command
>  - RelAdr -> Obsolete
>START/STOP UNIT command
>  - START/STOP UNIT command -> START STOP UNIT command
>  - Codes for Power conditions -> START_VALID, ACTIVE, LU_CONTROL,
>    FORCE_IDEL_0 and FORCE_STANDBY_0 are added, Code=5h is Obsolete
>SYNCHRONIZR CACHE command
>  - SYNCHRONIZE CACHE command -> SYNCHRONIZE CACHE (10) command
>  - Reserved -> SYNC_NV bit
>  - RelAdr -> Obsolete
>  - Reserved -> GROUP NUMBER field
>VERIFY (10) command
>  - RelAdr -> Obsolete
>  - Reserved -> GROUP NUMBER
>WRITE (10)/(12) command
>  - LUN (Obsolete) field -> WRPROTECT field
>  - Reserved -> FUA_NV bit
>  - RelAdr -> Obsolete
>  - Reserved -> GROUP NUMBER
>WRITE AND VERIFY (10) command
>  - LUN (Obsolete) field -> WRPROTECT field
>  - RelAdr -> Obsolete
>  - Reserved -> GROUP NUMBER
>
>Read/Write Error Recovery mode page
>  - Read/Write Error Recovery -> Read-Write Error Recovery
>  - Correction Span field, Head Offset count field, Data Strobe Offset
>    Count field -> Obsolete
>Informational Exception Control mode page
>  - Reserved -> EBF
>Power Condition mode page
>  - Idle Timer -> IDLE CONDITION TIMER
>  - Standby Timer -> STANDBY CONDITION TIMER
>
>ASC/ASCQ
>  - 11/07 RE-SYNCHRONIZATION ERROR -> 11/07 DATA RE-SYNCHRONIZATION
>ERROR
>  - 3/14/00 RECORDED ENTITY NOT FOUND Write -> 8/14/00 RECORDED ENTITY
>    NOT FOUND Read
>  - We shall not define Sense Key for the ASC/ASCQ which is not
>    specified to be used for Mt.Fuji devices.
>
>Best Regards,
>
>Harry Ai
>VEBU
>Panasonic AVC Networks Company
>Matsushita/Panasonic
>Osaka, Japan
>
>
>
>---------------- Start of the original message ----------------
>>From: takeshi_kohda at post.pioneer.co.jp
>>To: mtfuji5 at avc-pioneer.com
>>Cc: t10 at t10.org
>>Date: Tue, 20 Dec 2005 14:45:22 +0900
>>Subject: Fuji6 rev100 DRAFT
>>
>>Dear all,
>>
>>After the publication of rev 0.99, I have reviewed through the document
>and
>>corrected some inconsistency between Fuji and MMC, SPC.
>>The updated document is available on the fuji ftp site.
>>
>>ftp://ftp.avc-pioneer.com/Mtfuji_6/Spec/Fuji6r100DRAFT_diff.pdf
>>or
>>ftp://ftp.avc-pioneer.com/Mtfuji_6/Spec/Fuji6r100DRAFT_diff.zip
>>
>>Please check the section 1.9 Change history and colored portions in
>this
>>document.
>>
>>Best regards,
>>---
>>Takeshi Kohda
>>
>
>----------------- End of the original message -----------------
>
>
>
>
>
>
>
>
>
>
>

----------------- End of the original message -----------------


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