This message is from the T13 list server.
> Subject: RE: [t13] RE: countable data bytes > From: Larry Barras [mailto:[EMAIL PROTECTED]] > Sent: Mon 1/13/2003 6:31 PM I'm dividing my reply into "countable data bytes", and "Reading last block", hopefully that helps. > 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. Sorry I was unclear. I do NOT mean to say I disagree with Apple's QA1179 decision to obstruct SCSI CDB pass through to the HDD, CD, DVD ... that have op x12 Inquiry byte[0] & x1F PDT in x 00 05 07 0E. As you kindly point out, I don't know enough about Mac OS X to disagree. I mean to say only that I haven't seen that decision explained credibly, coherently, concisely, publically. > misunderstanding ... > available to a developer who needs to do this. I'm a developer, I need to do this, it was easy on Dos, Linux, & Windows. What's up with Mac OS X. Too new for its answers to appear weighted properly in Google? > First, sending CDB's directly to certain kinds of > drive hardware under Mac OS X, from *application > space* is specifically disallowed. This is what's either nuts, or else too stunningly creative for me to appreciate at a glance. > Mac OS X is not the only operating system with this > design enforcement. Mac OS X differs from Dos, Linux, & Windows here. Somehow everyone has forever been unable to name these other OS that are similarly limited. > These were decisions not arrived at lightly. Just secretly & seemingly ineffably. > 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. Yes, arbitrary pass through is hard to do well. Takes work to add value. Usb standard cites thirteen cases easy to distinguish, implementations often have to distinguish more than that. > Some controllers are capable of doing odd > byte-count DMA. Others are not. True without double buffers. But WITH double buffers, all are capable of appearing to have copied precisely a desired count of bytes. > Some controllers are capable of doing odd > byte-count DMA. Others are not. 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. Yes, this I will answer more clearly back in the "countable data byte" when next the bandwidth limit allows. > Perhaps efforts at advocacy would be better spent ... Ah, another "online metadiscussion grows without bound" experiment ... > 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. I can't get a "developer relations contact" for free, can I? Please understand, for this kind of development, I'm NOT paid. Here I'm not an @i... developer, here I'm just an open source developer, with some time but no money. > The Developer Relations group will indeed take the > matter for all due consideration. Perhaps efforts > at advocacy would be better spent there? Is http://lists.apple.com/mhonarc/ata-scsi-dev/ the wrong place to learn how to share my pain with Apple Developer Relations? Here in [EMAIL PROTECTED] I responded to the statement: > To: [EMAIL PROTECTED] > Sent: Wed 1/8/2003 5:08 PM ... > you should have absolutely no problem accessing the > last physical block of an ATA HDD on either the > classic Mac OS or OS X on any Mac that shipped in > the last 4-5 years. With Mac OS X, I'm dead in the water, after very little work sufficed to make Windows/ Linux/ Dos work. I don't equate dead in the water with "absolutely no problem". > > credibly, coherently, concisely, publically. For example, the day AFTER we began talking here, inside: http://lists.apple.com/mhonarc/ata-scsi-dev/ we have: http://lists.apple.com/archives/ata-scsi-dev/2003/Jan/10/scsipassthrulackstillune.txt Date: Thu, 9 Jan 2003 11:15:36 -0800 From: Garth Cummings <[EMAIL PROTECTED]> That help from Apple begins a burst of posts that for the first time to ignorant me suggested that a Mac STUC pass thru is by definition a pass thru that does not require root privilege. That's a cool new thing for real live paying customers in the field, sure, but it's not what I mean to be talking about. I mean to be talking about lab work, where I do ab/use root privilege. For example, how do I pass thru op x25 ReadCapacity, grab the reported maxLba, and then read/write that Lba. Currently, with Mac hardware, I boot into some other O.S. and talk there (Open Firmware, Connectix Virtual PC, whatever). > Second, the drivers are not compiled into the > kernel itself. There should be no need at all to > patch the kernel. This is just a conflict over jargon, sorry. What I was told is that I need a "kext" i.e. a "kernel" "extension" to pass thru an ATAPI CDB. Untrue? In my ignorance, I termed that a "kernel patch". Certainly, I've been told installing such a thing requires root privilege. > Just because there is no application interface > available from Apple doesn't mean a developer > cannot make his own. This isn't so very clear. The Apple experts I know personally in the real world were taught how to do this for money under NDA. Apple has reacted so violently to the idea of doing this, made such a show of consciously being unhelpful, that every expert I know personally tells me they can't help me, for fear of NDA. Even apart from the NDA infection, as far as Google knows, there's nothing for Mac OS like the tutorials of Windows, Linux, & Dos. > That's why Apple provides code via open source. Please correct me if I err, I hear Apple publishes the I/O stack only under its own custom definition of open source and carefully does not publish all the GUI and I/O code, even there. > ... Pat LaVarre
