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/DiscAr...
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