Mt Fuji meeting follow-up: Media Eject request condition clarification
keiji_katata at post.pioneer.co.jp
keiji_katata at post.pioneer.co.jp
Wed Jul 4 22:50:30 PDT 2007
* From the T10 Reflector (t10 at t10.org), posted by:
* keiji_katata at post.pioneer.co.jp
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$B$KJV?.$7$F$/$@$5$$(B
$BAw?.<T(B: owner-mtfuji5 at avc-pioneer.com
$B08 at h(B: <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>
$B7oL>(B: 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.$B!I(B
$B!H(BNote: Usually two Events are generated when the user requests an
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).
$B!H(B1h EjectRequest The Drive has received a request from the user
mechanical switch on the Drive) to eject the specified slot or media.$B!I(B
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$B!G(Bs request is to clarify the specification so there is no
Microsoft$B!G(Bs requirements as part of the clarification:
Bare minimum is that the device SHALL report user$B!G(Bs eject request when
That the device further reports user$B!G(Bs eject request when the tray is
is nice to have, but not mandatory. However, IF devices report user$B!G(Bs
request when the tray is not locked, then this behavior SHALL be consistent
across devices. If devices do NOT report user$B!G(Bs eject request when the
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$B!G(Bs proposal as clarification:
Removable Medium feature version is increased from 0000b to 0001b.
Add note: $B!H(BLogical unit shall report all eject requests from the user
of the locked or unlocked state of the tray.$B!I(B
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