> Hmm. If SCSI drives are anything like ATAPI drives (and here I confess I
> haven't checked), the first I/O after the eject button is pressed will
> come back with a marker (eg. check condition) with sense information that
> indicates that a user eject was requested.
The page at
http://www.microsoft.com/hwdev/respec/storspec.htm
says:
Storage-Related Specifications from Microsoft
The download documents on this page are in Microsoft(R) Word
format. After unzipping, these files can be viewed in any text
editor, including all versions of Microsoft Word, WordPad, and
Microsoft Word Viewer. (This link points to instructions on how
to view and print documents in Microsoft Word.)
[It's an RTF file, so perhaps the "any text editor" claim could be
considered true.]
Media Status Notification Support Specification, Version 1.03
(Download: 44K RTF file, published: March 1996; file date = May
20, 1996)
Specifies, for ATA and ATAPI devices, the protocol for
communicating when the user wants to eject the medium or has
inserted a new medium. Published by Microsoft Corporation.
Important: For CD-ROM and DVD-ROM drives implementing Media
Status Notification, the latest version of packet-based Media
Status Notification specification is actually a subsection of
the Mt. Fuji specification, which is the command set
specification for DVD-ROM that will be released as document SFF
8090. For CD-ROM and DVD-ROM drives, do not use Media Status
Notification specification v. 1.03 or earlier, as this version
of the specification does not apply to optical storage devices.
For complete information, see the current PC System Design
Guide.
...
Media Status Notification Specification for SCSI and ATAPI
Devices, Version 0.1
Specifies, for ATAPI and SCSI devices, the protocol for
communicating when the user wants to eject the medium or has
inserted a new medium. Published by Microsoft Corporation.
DRAFT: Media Status Notification Specification for SCSI and
ATAPI Devices, Version 0.1
(Download: 45K RTF file, published: March 1996; file date = May
30, 1996)
[The first of the latter two is in HTML; the second of them is in RTF.]
The 0.1 specification (the HTML one, at
http://www.microsoft.com/hwdev/respec/scsimed.htm
) says
A major shortcoming of removable media devices on PC platforms
is their inability to report to the host when the user attempts
to eject the medium. Currently most removable media devices
just eject the medium when the user presses the Eject button,
and potentially any data the operating system has not saved to
the device is lost. Various volume tracking and locking schemes
reduce this risk, but do not eliminate it. Ideally, devices
will have a means of communicating to the host that the user
wants to eject the medium or has inserted a new medium.
This specification defines a protocol for providing this
function for SCSI ATA and ATAPI devices. The support is enabled
using a new SCSI command, ENABLE MEDIA STATUS, and the media
status is retrieved using a new SCSI ATA command, GET MEDIA
STATUS.
Because it is difficult for a SCSI target to asynchronously
interrupt the host due to lack of industry support for
Asynchronous Event Notification, the GET MEDIA STATUS command is
not completed by the target until a media status change occurs.
If tagged command queuing is not supported by the target and/or
the host, a means of polling the target for status changes is
also specified. Note that in some controllers the unused words
in the ID Drive data are returned as 0FFFFh. Thus it may be
better if the Status Notification support was returned as a 2
bit field, where 00b, 11b are both defined as drive not
supporting Status notification.
I suspect this is mainly intended for devices such as Zip drives (note
the comment about "potentially any data the operating system has not
saved to the device is lost").
The 1.03 version mentions only ATA drives, saying
A major shortcoming of removable media devices on PC platforms
is their inability to report to the host when the user attempts
to eject the medium. Currently most removable media devices
just eject the medium when the user presses the Eject button,
and potentially any data the operating system has not saved to
the device is lost. Various volume tracking and locking schemes
reduce this risk, but do not eliminate it. Ideally, devices
will have a means of communicating to the host that the user
wants to eject the medium or has inserted a new medium.
This specification defines a protocol for providing this
function for ATA and ATAPI devices. The support is enabled
using a SET FEATURES command, and the media status is retrieved
using a new command, GET MEDIA STATUS.
Because it is difficult for an ATA drive to asynchronously
interrupt the host when it is not the active drive, this scheme
is implemented by the host polling the device for status.
This sounds different from the "sense information that indicates that a
user reject was requested" stuff you mention; I don't know whether any
drives implement either of those specs (0.1 for SCSI and 1.03 for ATA?).
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
