New SCSI Driver for Mac OS X

Charles Davis cdavis at mymail.mines.edu
Wed Apr 28 20:28:25 CDT 2010


On 4/28/10 5:48 PM, Ken Thomases wrote:
> On Apr 28, 2010, at 6:18 PM, Charles Davis wrote:
> 
>> Besides, to use it, we'd have to call DADiskMount() directly instead of
>> going through diskutil.
> 
> Huh?  Who goes through diskutil?
NTDLL, when it gets a FSCTL_DISMOUNT_VOLUME.
>  Who would have to call DADiskMount()?
The same.
>  And why do you think DADiskMount() is necessary to register approval callbacks?  That's not my understanding.  One gets the DADiskRefs for the mounted disks via the disk-appeared callback.
Sorry, I should have taken a closer look. I forgot about the approval
callbacks.
> 
>> Which means we'd have to add some code to
>> support DA to NTDLL. I don't know what AJ thinks of that.
> 
> There's already DiskArbitration support in mountmgr.sys, added by Alexandre.  :)
I knew that.
> 
> At one point he tried using an unmount approval callback to have Wine close all of its handles for files on the device, but DA wouldn't even ask the callbacks if there were files open.
Right, because it will refuse unless you tell it force-unmount.
>  I believe that has changed in Snow Leopard and we could revive that approach.  That way, unmounting volumes would just work seamlessly without the need for the user to invoke eject.exe.so.
Cool. Maybe we should look into that.
> 
> But, anyway, there's no barrier to registering such an approval callback.
Like I said, it will work when ejection and unmount requests go through
DA, but not for raw umount(2) or ioctl(2) with DKIOCEJECT.
> 
> 
>>> 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.)
> 
> OK, although I don't know if you have an easy way to actually be told when a process terminates,
I don't, but I have *a* way:

The driver registers a kernel event socket (<sys/kern_event.h>) and
kernel control socket (<sys/kern_control.h>). A daemon connects to both
sockets. The daemon listens for events on the event socket. Every time
the driver is told to lock the drive, it sends an event to the daemon.
When the daemon gets this event, it adds the process it got to a list of
processes for which it waits to die. When a process dies, the daemon
sends a control message to the driver, and the driver unlocks the drive.
Finally, every time the driver is told to unlock the drive, it sends
another event to the daemon, which removes the process from the list.
> or to link the lock to the process so it's automatically removed on process termination.
Keep an OSSet of proc_t's that have locked the drive. Then when I get a
note from the daemon, I unlock the drive.
> 
> -Ken
> 




More information about the wine-devel mailing list