This message is from the T13 list server.
Others have chimed in here already, but this is my direct experience:
1. It is not prohibited for a host send a command that is not indicated as supported in the identify data.
2. The device should report command aborted if it does not support the command.
3. In actual practice, one can expect that some devices will not respond in a nice way when given commands they don't indicate explicit support for.
Conclusion: It is a much better practice for hosts to avoid sending commands related to features which are not supported by the device as indicated by the identify data.
The two particular cases that come to mind are both situations where the device vendor had planned support for a feature, put it in silicon, then discovered later that there was a problem, after the point where they could rev their silicon. So they just flipped off the bits in identify device. However, that left them with silicon that was partially or errantly trying to satisfy the command rather than aborting it.
It's one of those, "why go looking for trouble?" situations.
At 11:40 AM -0700 5/26/04, Nathan Obr wrote:
Hi all,
I have what I believe is the spirit of the law question.
If a device doesn't report that it supports a feature in its IDENTIFY_DATA is it acceptable to send it commands from that feature set anyway?
For example: If a device doesn't report support for the Media Status Notification feature set is it acceptable to send it the GET MEDIA STATUS command anyway?
I don't see anywhere in the spec that prohibits this behavior, so first off, am I missing the section that says you shall not do this? Is it bad behavior to do this?
Thanks, Nathan
--
--------------------- I make stuff go. --------------------- Larry Barras ATA CPU Software Apple Computer Inc.
