Removable Media Status Notification feature set of ATA.
Here I suppose we mean the ATA ops x EF 95, x EF 31, and xDA.
I remember WHQL sometimes required the device to support those ops, but last I checked the relevant WHQL test erroneously required op xA0 03 Packet/ Request Sense to leave the x3F6 & x01 ERR bit unchanged, ouch, e.g. even in the presence of a UDMA CRC failure.
I believe that this function is overlapped to SBC/MMC command set (Packet)
Yes redundant with PDT x05 MMC op x4A GPCMD_GET_EVENT_STATUS_NOTIFICATION.
Massively distributed as legacy for PDT x 0E/ 07/ 04/ 00 RBC/ SBC ... I mis/remember mostly I studied this in the Win 95 B ATAPI that couldn't copy odd lengths of bytes per cdb. Rumour, be it truth or slander, says Win XP/ 2K didn't bother with these ATA ops.
Are you saying someone is trying to revive them? Please no?
and is incomplete to use in product.
Incomplete as you describe below, yes.
So in MMC/Fuji discussion we were concluded that Packet device and its host software does not use this feature set in ATA.
Yes please.
MMC has embedded changer model. SBC/MMC have many different write protects
or similar media and device combination status. Removable Media Status
Notification feature set of ATA cannot cover these items.
ATA layer persistent prevent, C/DVD class layer persistent prevent and
application layer prevent may conflict each other.
Yes.
I think if T13 group needs to keep this feature in ATA, someone must explain this feature in MMC WG.
Accurate doc would be nice, sure.
The design element I maybe most enjoyed was having the host conclude that an SBC op x2B Seek was an MMC op x2B Seek Immediate which completed not when x3F6 Status & x40 DRDY rose but instead prematurely when op xDA set x3F6 Status & x01 ERR rose because the disk was write-protected.
And T13 group may need to add some descriptions to keep compatibility with SBC/MMC command set.
Can you say more about what you have in mind?
I'm waiting for any commnet.
Hope this helps.
Pat LaVarre
