Date: Tue, 20 Jun 2000 23:46:56 -0700 From: Guy Harris <gharris@flashcom.net> To: Mike Smith <msmith@freebsd.org> Cc: "Kenneth D. Merry" <ken@kdm.org>, FreeBSD current users <FreeBSD-current@freebsd.org> Subject: Re: -e option to umount? Message-ID: <20000620234656.A355@quadrajet.flashcom.com>
next in thread | raw e-mail | index | archive | help
> 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 majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000620234656.A355>