MMC Get Event Status Notification and Windows
On This Page
 | Purpose and Requirements |
| Introduction |
| Functional Behavior Guidelines |
| Windows Logo Program |
| Resources and Call to Action |
Purpose and Requirements
This article provides information about how to implement the GET EVENT STATUS NOTIFICATION commands for Multi-Media Command Set-5 (MMC) compliant devices for Microsoft Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008 and future versions of the Windows family of operating systems.
This article provides vendors with guidelines for implementing these commands to take advantage of the built-in support provided in Windows. It is expected that the reader of this article is familiar with the MMC specification as relates to GET EVENT STATUS NOTIFICATION.
Introduction
The Multi-Media Command Set-5 (MMC) and Mt. Fuji-7 specifications describe a command to help the operating system acquire information about device behavior changes. This GET EVENT STATUS NOTIFICATION command set applies to all Type 5 devices, including CD-ROM, CD-R, CD-RW, DVD-ROM, DVD-RAM, DVD-R, DVD-RW, DVD+R, DVD+RW, HD DVD-ROM, HD DVD-R, HD DVD-RW, HD DVD-RAM, BD-ROM, BD-R, BD-RE and so on, which are referred to in this article as MMC-compliant storage devices.
The proper implementation of these commands, together with operating system support, can result in improved autorun time, better user interface results, better time estimates for long operations, and many other user benefits.
Historically, some incompatible or non-compliant methods of implementing this command resulted because of the lack of available tests and some ambiguity in the specification documents.
This article, together with the 2008 Microsoft WHQL optical device test, is provided to help clarify the specification and to improve implementations for efficiency within the Windows operating systems.
The following guidelines are based on these assumptions:
| • | An MMC-compliant storage device supports N discrete Event Class types of events with N strictly higher than 0. |
| • | An event is considered NoChange if bits 0-3 (Event Code Field) of byte 0 of the returned Event Descriptor are zero. |
Functional Behavior Guidelines
To ensure the best compatibility with Windows operating systems, the following functional behavior regarding the GET EVENT STATUS NOTIFICATION command is required.
| • | Requests for a Notification Class of zero must return an event header with the NEA bit set, the Notification Class field set to 000b, and the Supported Event Classes byte set to reflect all N supported Event Classes. | ||||||||||
| • | Requests may arrive at the device from a host requesting any subset of events that the device supports. For example, if { OpChange, DeviceBusy, Media } events are supported, then any of the following events may be requested by the host by a single command block:
| ||||||||||
| • | The data reported by the drive to the host must contain exactly one Event Class. | ||||||||||
| • | The data reported by the drive to the host must contain an Event Class that was requested by the host in the command block. | ||||||||||
| • | The data reported by the drive to the host must not report a higher priority Event Class if the Event Class was not requested by the host. | ||||||||||
| • | If multiple Event Classes are requested by the host in a single command block, the drive must follow the following procedure to determine the Event Class to report to the host: For each requested Event Class, in order of priority per the specification:
| ||||||||||
| • | The drive must simultaneously support (or queue) at least one event of each Event Class which it supports. This prevents events of different Event Classes from interfering with each other. For example, if a Media Event and External Request event both occur at the same time, and the host is continuously requesting both event types, then the drive must:
|
To support such behavior early, the following high-level design of firmware to support GET EVENT STATUS NOTIFICATION should be considered. This does not preclude other implementations if the device behaves as expected by the operating system.
For each supported Event Class, have a queue of appropriate depth (typically 1) of events for that Event Class. For drives that support the Mt. Rainier format, the minimum appropriate queue depth is 2, and special handling should be given to both the BGFormatCompleted and BGFormatRestarted Media Events.
To implement this more simply, and to avoid queue depths greater than one, logically use a queue depth of 1 for the Media Events unless one of the BGFormat events is supported. When an event is generated by the device, the device looks to see if the new event is of greater priority (per the MMC specification) than the current event that is stored of that class. If it is, the new event replaces the existing event in the 1-deep queue for that Event Class. Otherwise, the new event is discarded.
In addition, in the case of the events { BGFormatCompleted, BGFormatRestarted }, these events must be placed into the "BGFormat," but never the "Media" queue. Similarly, other Media events must always go into the "Media," and never the "BGFormat" queue. When the device is searching for which event to report to the host, the "BGFormat" block may be logically considered an event of priority less than "Media." Any or all of the blocks mentioned may be removed if the related Event Class is not supported.
Windows Logo Program
Current "Designed for Windows" Logo Program requirements for GET EVENT STATUS NOTIFICATION support are defined in the Microsoft Storage Devices logo requirement from Winqual logopoint.
Resources and Call to Action
Call to Action:
| • | For system manufacturers: Require that drives for your systems implement GET EVENT STATUS NOTIFICATION as described in this article. |
| • | For firmware engineers: Implement firmware that supports behavior that is compatible with Windows, as described in this article. |
| • | For device manufacturers: Require firmware which implements GET EVENT STATUS NOTIFICATION as described in this article. |
Feedback:
| • | To provide feedback about this article or the Optical Logo Test, send e-mail to storwdk@microsoft.com. |
Resources:
| • | Windows Platform Development white papers and resources for storage technologies: |
| • | Windows Driver Development Kit: |
| • | Windows Logo Program for Hardware: |