Fuji meeting request

keiji_katata at post.pioneer.co.jp keiji_katata at post.pioneer.co.jp
Thu Nov 20 02:57:38 PST 2003


* From the T10 Reflector (t10 at t10.org), posted by:
* keiji_katata at post.pioneer.co.jp
*
Hello all,

I would like to propose to have a Fuji Meeting in December.
Here is the proposed agenda and schedule. I wrote questions in proposed
agenda items. Please send your favor to reflector or me.
Please send your comment about date and place.

Agenda items:
1. Fix the problem of Device Busy Event
2. Fix the problem of Get Performance format 3 Write Speed
3. Modification of Operational Change Event description
4. Other

Meeting date and place:
2003/12/15 Monday
Pioneer Meguro Headquarter 12F, Tokyo, Japan.


1. Fix the problem of Device Busy Event

In the November MMC4 WG meeting, WG member concluded that reader may
understand that Device Busy Event description have two different
capabilities. One is time-out event reporting of queuing environment.
Another is progress indication of non- queuing environment. Here is
inconsistency, so one of them or both should be removed. This is written in
MMC minutes.
--- 6.7 GET EVENT STATUS NOTIFICATION, MMC minutes ---
Conclusions:
2. By following prior descriptions precisely (particularly in Fuji), the
command has no value in the ATAPI environment. Given this, Bill McFerrin
(Philips) noted that Device Busy has no practical value and should be
removed from MMC4.
------------
These two different definitions do not work with current SAM (SCSI
Architecture Model). This provides tagged task management for Bus topology
e.g. iSCSI or Home Bus. In case of ATAPI device, GET EVENT STATUS
NOTIFICATION command of Device Busy Event provides progress indication to
application. In case of iSCSI device if it uses tagged task management, GET
EVENT STATUS NOTIFICATION command of Device Busy Event provides time-out
event notification to application. To begin with, how can the application
know the environment of the device connection that is queued or non queued?
MMC is the standard that is independent from hardware. I agree with Bill's
statement that one of them or all should be removed.

Q1: Question to survey the member's preference.
I would like to survey the member's preference. Please send your opinion to
reflector. What is your favor in following 5 options? In case of option 1-4
and 1-5, your proposal is appreciated.

Op1-1. Device Busy Event shows the progress indication in time unit only.
Remove time-out event report capability from device busy event.

Op1-2. Device Busy Event shows the time-out event only.
Remove description of the progress indication capability.

Op1-3. Remove (obsolete) Device Busy Event
Remove Device Busy Event at all.

Op1-4. Device Busy Event shows both of the time-out event and the progress
indication.
Refine the description to fix the technical inconsistently. Please post
your proposal.

Op1-5. Other
Please post your proposal


2. Fix the problem of Get Performance format 3 Write Speed

Current Get Performance command format 3 Write Speed does not have non-pure
CLV rotation control. Therefore there is no difference in the response data
between 6X CLV and 6X-8X ZCLV. Both have 6X speed for the lowest Write
Speed. The other hands, current Set CD Speed command and Mode Page 2Ah have
opposite description that Speed field reports the highest speed (most outer
radius speed). It is necessary to fix this technical problem.

Q2: Question to survey the member's preference.
I would like to survey the member's preference. Please send your opinion to
reflector. What is your favor in following 3 options? In case of option
2-3, your proposal is appreciated.

Op2-1. Change the description same as Mode Page 2Ah.
Originally, Mode Page 2Ah and Write Speed descriptor have same result. Both
showed the most inner radius write speed. But Mode Page 2Ah is changed the
description from the most inner (lowest) to the most outer (highest).

Op2-2. Assign ZCLV rotation control code to rotation control field.
Assign ZCLV code (e.g. 10b) to rotation control field.

Op2-3. Other
Please post your proposal.


3. Modification of the Operational change event
In MMC4 WG, Operational change event description is changed to be simple.
But it is inconsistency between MMC4 and Fuji 5. Fuji Document modification
should be discussed.


4. Other
Please post your discussion item if any.


Best regards,

Keiji Katata
PIONEER CORP.



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