Mt Fuji meeting follow-up: Media Eject request condition clarification

David Burg daviburg at windows.microsoft.com
Thu Jul 5 02:24:54 PDT 2007


* From the T10 Reflector (t10 at t10.org), posted by:
* David Burg <daviburg at windows.microsoft.com>
*
Hi Katata-san,
If no eject request shall be generated when the tray is not locked, then the
note "Usually two Events are generated when the user requests an eject:
first, an EjectRequest Event, and then a MediaRemoval Event" below table 287
in the same Fuji6r100 is at best confusing. Could it be that the intend of
this note was what is described in MMC5r04's 4.1.7 "The Drive only generates
GET EVENT STATUS NOTIFICATION (EJECT REQUEST) events after reporting a GET
EVENT STATUS NOTIFICATION (NEW MEDIA) event, and prior to reporting a GET
EVENT STATUS NOTIFICATION (MEDIA REMOVAL) event for the given media."?
Regardless, you explained earlier two types of implementations, type 1 and
type 2. That there are two types of implementations in the market means that
the specification leaves room for interpretation, right?
Best regards.
David Burg.
-----Original Message-----
From: owner-mtfuji5 at avc-pioneer.com [mailto:owner-mtfuji5 at avc-pioneer.com] On
Behalf Of keiji_katata at post.pioneer.co.jp
Sent: Wednesday, July 04, 2007 10:51 PM
To: mtfuji5 at avc-pioneer.com
Cc: T10 Reflector; David Walp; Bhanu Gogineni
Subject: Re: Mt Fuji meeting follow-up: Media Eject request condition
clarification
Hi David,
I think you or other MS stuff may misunderstand Media Event system of
MMC/Fuji.
Please refer to 15.2.1 Morphing operation of Fuji6r100.pdf on page 378.
---- start ----
The Persistent Prevent state shall be maintained after the eject request. New
media that is inserted into the logical unit shall be locked in the logical
unit
after the logical unit generates or reports the NewMedia event. Prior to
generating or reporting the NewMedia event, the logical unit may eject media
without an explicit eject command from the host.
This allows the user to remove incorrectly inserted media without having to
wait
for host intervention. In this condition neither the NewMedia event nor the
EjectRequest event should be reported by the logical unit. Locking the tray
after generating the event allows for a simpler implementation; locking the
tray
after reporting the event allows a longer window of direct user intervention.
While in the Persistent Prevent state, the logical unit shall generate Events
upon receipt of a User Eject request. The logical unit shall not eject the
media
on receipt of these requests, if the logical unit has already reported a
NewMedia event for this media. If a logical unit allows an eject between
generating and reporting the NewMedia event, the logical unit shall remove
the
NewMedia event(s) from the Event queue.
---- end ----
Anyway, if host needs "EjectRequest event", host must set the drive into
persistent prevent condition. This is only described method in MMC&Fuji.
Best regards,
Keiji Katata
PIONEER CORP.
David Burg <daviburg at windows.microsoft.com>@avc-pioneer.com on 2007/07/03
09:39:04
mtfuji5 at avc-pioneer.comに返信してください
送信者:     owner-mtfuji5 at avc-pioneer.com
宛先:  <mtfuji5 at avc-pioneer.com>, "T10 Reflector" <t10 at t10.org>
cc:    "David Walp" <david.walp at microsoft.com>, "Bhanu Gogineni"
       <bhanu.gogineni at microsoft.com>
bcc:
件名:  Mt Fuji meeting follow-up: Media Eject request condition
clarification
Hello,
I would like to clarify the request for condition clarification of the
“Media
Eject request”.
The current MMC and Mt Fuji document leave room to interpretation as to when
will devices report this user request. The texts are:
Mt Fuji 7r08:
“1h EjectRequest
The logical unit has received a request from the user (usually through a
mechanical switch on
the logical unit) to eject the specified slot or media.”
“Note: Usually two Events are generated when the user requests an eject:
first,
an EjectRequest Event, and then a
MediaRemoval Event.”
This suggests that actually the event is reported regardless of the
persistent &
prevent bit (which makes it possible that the two events are generated one
after
another without the need for the host to pick up the request event and
execute/allow the actual eject).
MMC 5r04:
“1h EjectRequest The Drive has received a request from the user (usually
through
a
mechanical switch on the Drive) to eject the specified slot or media.”
There is no note in MMC.
Reported implementation interpretations [thanks to Katata-san]:
Type 1. When Persistent=1 and Prevent=1, drive reports EjectRequest on Media
Class Event.
Type 2. When Prevent=1, drive reports EjectRequest on Media Class Event.
Microsoft’s request is to clarify the specification so there is no longer
room
for interpretation.
Microsoft’s requirements as part of the clarification:
Bare minimum is that the device SHALL report user’s eject request when the
tray
is lock.
That the device further reports user’s eject request when the tray is not
locked
is nice to have, but not mandatory. However, IF devices report user’s eject
request when the tray is not locked, then this behavior SHALL be consistent
across devices. If devices do NOT report user’s eject request when the tray
is
not locked, then this behavior SHALL be consistent across devices.
Software must be able to distinguish between device which behavior is open to
interpretation (that is, all current drives) and drives that are design after
this specification clarification. This likely can be solved by increasing the
revision of Removable Medium feature.
Microsoft’s proposal as clarification:
Removable Medium feature version is increased from 0000b to 0001b.
Add note: “Logical unit shall report all eject requests from the user
regardless
of the locked or unlocked state of the tray.”
We are open to other proposals.
Best regards,
David Burg.
*
* 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