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

David Burg daviburg at windows.microsoft.com
Mon Jul 2 17:39:04 PDT 2007


Formatted message: <A HREF="r0707022_f.htm">HTML-formatted message</A>

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.



More information about the T10 mailing list