New SCSI Driver for Mac OS X

[Charles Davis]

On 4/28/10 5:02 PM, Ken Thomases wrote:
> Hi Charles,
> 
> Are the DKIOCPREVENT and DKIOCALLOW ioctls necessary?
They were the reason I first wrote the driver. I added DKIOCSCSICOMMAND
later.
>  DiskArbitration already has a facility for clients to refuse mount/unmount/eject requests.
> 
> http://developer.apple.com/mac/library/documentation/Darwin/Reference/DiscArbitrationFramework/DiskArbitration_h/
That only works on requests that go through DiskArbitration. I'm pretty
sure that won't stop a raw DKIOCEJECT (which by the way is what Wine
uses). How can it, when DKIOCEJECT goes straight to the kernel?

Besides, to use it, we'd have to call DADiskMount() directly instead of
going through diskutil. Which means we'd have to add some code to
support DA to NTDLL. I don't know what AJ thinks of that.
> 
> Among other things, if Wine uses your driver to lock the media and then crashes, is there any way for the user to recover and unlock the media?
Just send the device file a DKIOCALLOW, and then everything will be back
to normal.
>  Also, I don't know enough about the driver model to know if multiple user clients can compete or conflict for locking the media.  For example, if two processes lock the media and only one unlocks it, is it locked or unlocked?  DiskArbitration avoids these pitfalls.
It's unlocked. It's like the old handles. 10 calls to HLock() would be
undone by a single HUnlock(). I need to fix that. Luckily, the kernel
gave me the process that initiated the (un)lock, so I can keep track of
that. (Then I can also force the disk unlocked when it terminates.)
> 
> 
> Also, at <http://xnu-extras.git.sourceforge.net/git/gitweb.cgi?p=xnu-extras/xnu-extras;a=blob;f=ExtMediaBSDClient.cpp;h=154dbd709476e682e86f14891b2fbc9fb9efa311;hb=HEAD#l154>, there's a mismatch between "path+6" and "pathlen-5", no?  That's an argument for using strlcat, instead, isn't it? 
You're right. It's fixed now. (Personally, I'm surprised it didn't panic.)

Chip