Updated on Sunday, October 11, 2009 by Pat LaVarre

Storage/ PLScsi/ Mac/


http://tinyco.de/2009/02/04/writing-a-mac-osx-usb-device-driver-with-scsi-pass-through.html is the only open source example I know of someone who's gone and fixed the Mac kernel to support Windows DeviceIoControl SCSI_PASS_THROUGH_DIRECT like it should natively.

The old text below discusses how running the kernel as misdelivered by Apple lets you match that Windows service only when your device self-identifies as T10.org PeripheralDeviceType (PDT) x05 Dvd/Cd and otherwise NOT!

Kudos to Apple's (reasonably free reasonably public) ata-scsi-dev list for bringing the TinyCo.de work to my attention.

Send me e-mail to tell me you actually exist, making time to read this page, and I might get around to formatting it nicely. So far in my own life I haven't made the time to develop Mac OS X kernel patches myself, so long as we agree to discount mostly obsolete Open Mac Boot Forth exercises.


Updated on Thursday, July 15, 2004 by Pat LaVarre

Welcome, bienvenido, bienvenue!  Per your kind encouragement,

We have the 2004-07-14:

gcsmac.tar.gz

That's plscsi almost working on the Mac for "authoring" devices.

Known issues appear in blog if you search for "Mac" among the: plscsi issues

"Almost working" here now means only the gccscsi layer: as yet back port completed of the command-line parsing.  Also no examples yet, apart from op x12 "INQUIRY".

Nastiest remaining technical issue is the naming of devices.  Mac OS X naturally gives no name to the device: it's just the n-th "authoring" device found.  Possibly we should learn to make the free BSD disc name work, such as /dev/disk2.

Second nastiest remaining technical issue are the significant side effects of the open/ close in the launch-open-ioctl-close-exit sequence that's fundamental to the idea of plscsi at the command line.  In Mac OS X, open works only if preceded by diskutil unmount (that's "unmount" not "umount"), and close provokes automount, ouch.

[Note: You got this update to this web page courtesy the bug in Mozilla Composer that often substitutes file: links for relative http: links.  The PLScsi/ link here above was broken that way.]


Per the progress blogged at:

to plscsi for Mac OS X from "autut"

Mac OS X by design passes SCSI thru to "authoring" devices without root privilege, yet to no other devices despite root privilege, for reasons that ata-scsi-dev finds ineffable.  We now have plscsi working well enough on the Mac to hope to discover what a Mac OS X "authoring" device is in terms of t10.org primitives.

Our first guess: to connect without kext, a device has to claim PDT x05 = MMC and then report DVD/ CD writable in legacy mode page x2A.  That definition would make an "authoring" device out of any standard device that writes CD-R, CD-RW, DVD-R, DVD-RW, or DVD-RAM.  But that definition would exclude DVD+RW and other MMC that didn't also write one of those other kinds of discs, but maybe no such devices exist.


Seen 2004-03-27:

$ # _1 _2 _3 _4 _5 _6 _7 _8 _9 _A _B _C _D _E _F
$
$ ./inq
"PIONEER " "DVD-RW DVR-104 " "A227"
$
$ ./inq s0
x 12 00 00 00 24 00
x 05 80 00 32 5B 00 00 00 50 49 4F 4E 45 45 52 20 44 56 44 2D 52 57 20 20 44 56 52 2D 31 30 34 20 41 32 32 37
"PIONEER " "DVD-RW DVR-104 " "A227"
$
$ ./rc s0
x 25 00 00 00 00 00 00 00 00 00
x 70 00 02 00 00 00 00 0E 00 00 00 00 3A 00 00 00 00 00
file plscsi.c func yesx line 401
$
$ # insert disk, wait for mount on Desktop
$
$ diskutil unmount "/Volumes/Virtual PC 5.0"/
Volume /Volumes/Virtual PC 5.0/ unmounted
$
$ ./rc s0
x 25 00 00 00 00 00 00 00 00 00
x 00 00 25 1E 00 00 08 00
$
$ ./dn s0
sp_open: -8 = -x8
$
$ diskutil unmount "/Volumes/Virtual PC 5.0"/
Volume /Volumes/Virtual PC 5.0/ unmounted
$
$ ./dn s0
x 1B 00 00 00 00 00
$

As of now, our latest success was passing -i x24 -y "12 00:00:00 24 00", to an ATAPI DVD-RW and a USB DVD-RAM, thru a Mac OS X 10.3.2, without having installed the Developer's disc needed to rebuild the code:

$ ./spinq 0
HL-DT-STDVDRAM GSA-4081BA100
$ ./spinq 1
PIONEER DVD-RW  DVR-104 A227
$ ./spinq 2
sp_open: -4 = -x4
$
$ # unplug the USB DVD-RAM, leaving only the ATAPI DVD-RW
$
$ ./spinq 0
PIONEER DVD-RW  DVR-104 A227
$ ./spinq 1
sp_open: -4 = -x4
$
$ uname -srm
Darwin 7.2.0 Power Macintosh
$
$ date
Sat Mar 20 07:19:20 MST 2004
$



Saturday, January 24, 2004

My experiments in restructuring these pages to work with less blinking and scrolling may soon yield fruit.  Meanwhile,

Ouch I see I haven't updated this page for months, though I have been blogging.

Newer than the info of this page is our hope of SCSI pass thru, maybe since Mac OS X 10.2 or so, for virtually unplugged PDT x05 DVD/ CD devices:

scsi pass thru privilege denied by Apple

Perhaps also relevant are:

msft usb-storage faq found again

bInterfaceSubClass x06 Transparent SCSI, defined

Cypress USB2HS in Apple iPod

programmable disc editor

Apple Mac OS X man pages searchable

Google to fix blog noise problem



Updated on Wednesday, November 12, 2003 by Pat LaVarre

Storage/ PLScsi/ Mac/

Welcome, bienvenido, bienvenue!  Sorry to say, as yet:

"Write once, talk anywhere" for SCSI means any desktop or laptop that is Not a Mac.

Please write us to encourage our port of PLScsi to Mac OS X.

Share your interest! Share your knowledge!  Fun mysteries lie near here.

 

Other Mac Pages:

plforth/moforth/ with Pong on Mac

tools/pldd/ seen running on Mac

tools/knoppix/ may be Linux for Mac

hmug re Linux for Mac


See Also:

links to this page

previous edition

links to previous edition

Apple re Accessing Hardware

Apple ata-scsi-dev re STUC

Apple QA1179

 

1. Summary

Lately, kindly, offline we were asked to answer:

http://www.google.com/search?q=mac+plscsi+upgrade

> if only PLScsi supported the Mac,
> we would have DVRFlash for Mac too).

1. Thank you for encouraging our effort to port PLScsi to the Mac.

2. We wrote PLScsi, we have only Mac's at home, we want PLScsi to work on Mac.

3. Apple does not want PLScsi to work on Mac.

4. We lose, and you do too, even as late as Mac OS X 10.3.


2. Why Only the Mac Doesn't Work

In creating Mac OS X, Apple reworked the I/O of free BSD.  That rework excluded the free BSD ioctl SCIOCCOMMAND, whoops.

Via similar ioctl, when root-privileged, we see SCSI pass thru working in all of Linux, Win XP/2K, Win ME/9X, Dos and Mac OF (Open Firmware boot Forth.  Always we try ATAPI and USB, as yet we have tried FireWire only in Win/Dos (: noone has yet donated an iPod to us. :)

We hear Linux boots from CD on Mac, we wish we knew how.  We know Mac OF boots from Command+Option+O+F on Mac.  Rebooting outside of Mac OS X may violate your Apple warranty, just as roll-your-own firmware upgrade may violate your drive warranty.

Maybe true Mac "Darwin" geeks can patch Mac OS X with a "kext" to allow root privileged pass through.  We do not know how.

Noone knowledgeable has chosen to explain clearly why Apple exclude SCSI pass thru privilege from root privilege.  We know we do not understand.

We see root-privileged Mac OS X Terminal commands widely published that in fact overwhelm file permission security and closely resemble commands that smash your hard drive, e.g.:

sudo dd if=/dev/disk0 bs=512 skip=0 count=1 | hexdump -C

By faith we assume the Mac OS X design to omit SCSI pass thru has some coherent technical rationale.  We have requested and promptly received, time and time again, free expert help from Apple engineers of Apple's ata-scsi-dev newsgroup, yet the help we receive we find technically incomprehensible.  We do not understand, we do not know why.

A less concise presentation of our utter mystification appears in the previous edition of this page.


3. SCSI Pass Thru Design

Some people say pass through, some people say pass thru, some people say bridge.

Suppose, to bridge design, we try to apply the Internet design principle:

Be liberal in what you accept, be conservative in what you send.

In bridge design, we have to choose.  We can choose to trust an opaque bridge to translate the command, or we can choose to pass trouble thru a transparent bridge.  An opaque bridge is not liberal in what it accepts.  A transparent bridge is not conservative in what sends.  Ouch.  We conclude:

Bridges by definition cannot be well-designed.

Accordingly, here we collect ways in which SCSI pass thru crashes operating systems.

Early 2.4 Linux crashes if you try Inquiry for zero:

-y "12 00:00:00 00 00"

Linux folk corrected Linux immediately, naturally.

Win 2K crashes if you try mode sense of a header at a time with a device for which Windows incorrectly translate to op x5A Mode Sense (10) from op x1A Mode Sense (6):

-i 4 -y "1A 00:3F:00 04 00"

Microsoft corrected Windows immediately after we found a sponsor to pay Microsoft to listen to us, years after we found hints of the trouble, six months after we constructed a short demo.

Against the theory that bridges can't work well, we have one confusing counterexample.

Certain USB/ ATAPI PIO bridges actually do work well in practice.  With those, the host begins by passing to the bridge a complete description of how the host would have spoken ATAPI PIO.  The bridge at least once invisibly negotiates max PIO mode and thereafter transparently reproduces how the host would have treated a direct-attached device.  And that system works.

By contrast, bridges to ATAPI DMA don't work quite so well.  The standard description of how the host would have spoken ATAPI PIO doesn't mention how the ATAPI DMA host would have miscounted bytes with a direct attached device, so the bridge can't reproduce that behaviour exactly.

Posted by Pat LaVarre