Mt Fuji meeting follow-up: Media Eject request condition clarification
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>
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?
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
I think you or other MS stuff may misunderstand Media Event system of
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
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
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
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
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
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.
David Burg <daviburg at windows.microsoft.com>@avc-pioneer.com on 2007/07/03
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>
ä»¶å: Mt Fuji meeting follow-up: Media Eject request condition
I would like to clarify the request for condition clarification of the
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:
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:
an EjectRequest Event, and then a
This suggests that actually the event is reported regardless of the
prevent bit (which makes it possible that the two events are generated one
another without the need for the host to pick up the request event and
execute/allow the actual eject).
â1h EjectRequest The Drive has received a request from the user (usually
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
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
Microsoftâs requirements as part of the clarification:
Bare minimum is that the device SHALL report userâs eject request when the
That the device further reports userâs eject request when the tray is not
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
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
of the locked or unlocked state of the tray.â
We are open to other proposals.
* 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