This message is from the T13 list server.
Marushak, Nathan wrote:
I'm not sure I follow the need to specify the protocol. The assumption is we are passing through an ATA command to an ATA controller. As such, the "cumbersome (and unneeded) table or switch statement" has always gone with the ATA controller. Somebody has to perform the lookup to go from command type to the sequence type (data protocol), whether it be at the highest level, lowest level, or somewhere in between.
Certainly. Otherwise it would be impossible to execute vendor-reserved commands.
Given that the protocol is unknown for vendor-reserved commands, it follows that one must specify the protocol for vendor-reserved commands.
If one must specify the protocol in some cases, it then follows that the most efficient OS driver implementation is to require specification in ALL cases, thereby avoiding the lookup table / switch statement completely.
As far as vendor unique commands...good question. ATA Controllers have to understand that the command being passed to them is vendor unique. Understanding the command is vendor unique, then the controller won't make any assumptions about subsequent packets. Basically it will wait until it receives signals or FISes back from the target before understanding what the data protocol might be or what the next step is. I believe this is true in all cases.
Suffice to say, I don't believe the existing ATA controllers on the market require knowledge of each and every vendor unique command for each and every target on the market, yet they do still allow for vendor unique commands.
To summarize, I don't see the need to specify a data protocol since there currently is no need to specify data protocol in a SATA Register FIS.
Please look at how ultra-modern SATA controllers support vendor reserved commands ;-)
* Some vendors have a 'command protocol' field that must be filled in for each command issued.
* Some vendors have special 'vendor command setup' commands, snooped by the host controller, which specify this information to the host controller.
* A few vendors with bridged SATA implementations simply don't support vendor reserved commands at all, because it is impossible to 'tell' the controller the FIS protocol.
* The remaining vendors seem to have chosen to allow direct control over FIS transmission/reception by the low-level driver, so that the driver may ensure that the command protocol is followed for the cases where the host controller silicon / firmware doesn't know how to handle the command.
The people actually making the controllers recognized the need to allow the OS driver to specify the data protocol, precisely because it is _impossible_ to know the protocol in all cases.
I have recognized this requirement, and have implemented this for the following vendor's controllers, where possible: Intel, Silicon Image, Marvell, Promise, Vitesse, VIA, SiS, and Broadcom/ServerWorks.
Jeff
