This message is from the T13 list server.
At 3:58 PM -0700 1/11/03, Pat LaVarre wrote:
Pat appears to be in disagreement with a design decision made at Apple to disallow applications from directly sending CDB's into certain classes of drive hardware. Pat certainly has a right to his opinion. Although I will say that Pat seems to be displaying a certain level of misunderstanding about how the stuff really works and what is available to a developer who needs to do this.As we speak, Mac OS X is trying out the idea that you have to patch the kernel if you want the privilege of authoring your own Cdb's for HDD/ CD/ DVD. I'd say that effort isn't going well, but it's too soon to know.
First, sending CDB's directly to certain kinds of drive hardware under Mac OS X, from *application space* is specifically disallowed. Mac OS X is not the only operating system with this design enforcement. These were decisions not arrived at lightly.
Second, the drivers are not compiled into the kernel itself. There should be no need at all to patch the kernel. Just because there is no application interface available from Apple doesn't mean a developer cannot make his own. That's why Apple provides code via open source.
We also have a Developer Relations group. If a developer has an issue that interferes with the business of shipping his product, the best place to go is his developer relations contact. The Developer Relations group will indeed take the matter for all due consideration. Perhaps efforts at advocacy would be better spent there?
Under Mac OS X SPI (System Programming Interface) for dispatching CDB's into hardware, the byte count per transfer is not determined on the basis of the CDB. The count is a separate field of the command object structure. For ATAPI devices, if the device byte count does not agree with the value from the command structure, the controller driver will attempt to reconcile the difference if possible. Otherwise, the command will usually be returned as a failed IO to the device driver stack.
Under Mac OS X, IO requests for data from ATA disks are directly interpreted into an ATA command and sent to the controller. The driver at this layer also manages power states, resets and configurations and so on. Since there is no CDB layer for ATA hard drives, there is no CDB interface possible anyway.
At 10:54 AM -0700 1/10/03, Pat LaVarre wrote:
Pat's discussion of sending odd-byte counts in a CDB to the W95 API is a prime example of WHY someone would choose to restrict CDB access. Some controllers are capable of doing odd byte-count DMA. Others are not.Let's try a concrete example, a bus trace I remember well. Suppose an app passes -x "12 0 0 0 05 0" -i 5 thru Win 95 B to an ATAPI device. (That coded hex is an Inquiry for up to 5 bytes copied into a 5 byte buffer. People like 5 bytes because the additionalLength field appears at offset 4.) After CommandOut, a device built to spec will respond with x1F2 SectorCount & x03 = x02 DataIn and x1F5:1F4 Cylinder = ByteCount = x0005. Win 95 B will then hang, til its 7+/0.5s timeout.
It is unlikely that an application would be able to determine this, but the drivers should be able to figure out how to accomplish this without hanging the drive/system/bus, etc.
If you are going to play like a driver, then you have to take on all responsibility of a driver, including figuring out what might work and what might not, how not to leave hardware in a bad state, how to respond to errors and so forth.
--
---------------------
I make stuff go.
---------------------
Larry Barras
ATA CPU Software
Apple Computer Inc.
