ntdll/cdrom : implement CDROM_Verify to work on Mac Os

[James McKenzie]

On 1/1/11 4:07 AM, maury loïc wrote:
> On Sat, Jan 1, 2011 at 2:22 AM, James McKenzie 
> <jjmckenzie51 at earthlink.net <mailto:jjmckenzie51 at earthlink.net>> wrote:
>
>     On 12/31/10 1:50 PM, Charles Davis wrote:
>
>         On 12/31/10 1:11 PM, Ken Thomases wrote:
>
>             I should add that this patch seem correct to me.  It
>             couldn't hurt to get Charles Davis's input, of course.
>
>         I agree, for now. He should at least put a comment in to the
>         effect of
>         "if we got this far, there's already media in the drive."
>
>     That was the point I was trying to get to.  Based on Ken's comment
>     below, the device is temporary and only exists for the time period
>     that the device is in use.
>
>             MSDN documents that the purpose of IOCTL_*_CHECK_VERIFY is
>             to check if the media has changed.  The Linux and FreeBSD
>             implementations basically just check if there's media in
>             the drive.  On Mac OS X, the BSD device file just plain
>             doesn't exist unless and until there's media mounted.
>              There's no permanent BSD device file for the drive
>             itself.  So, if CDROM_Verify() is called, which requires
>             that the BSD device file is opened and thus is present,
>             that by itself implies that there's media in the drive.
>              Therefore, CDROM_Verify() should just return success.
>
>         Makes sense. But the 'right' way to implement this on Mac OS
>         is to ask
>         DiskArbitration to tell us when the media changes. (In fact,
>         the right
>         way to implement this elsewhere is to ask udev or hald the
>         same thing.)
>         Then we can return STATUS_VERIFY_REQUIRED (as documented) when
>         the media
>         actually has changed. For now, though, Loïc's patch is OK.
>
>     Is this going to be changed sometime in the future to work per the
>     documentation?
>
>         AJ wants to eventually move some (all?) of the disk/CD/DVD/storage
>         IOCTLs into mountmgr anyway, where Wine's fake storage drivers are
>         hosted. Mountmgr already has infrastructure in place to talk
>         to DA on
>         Mac OS and to hald on Linux/FreeBSD, so doing this the 'right'
>         way will
>         be much easier there.
>
>     This is a good point.  Maybe the effort should be to move the code
>     over to mountmgr.sys rather than implement and have to move it later.
>
>     And I am aware what the process is, I was asking general questions
>     based on what the comments were in the patch.  Basically, the
>     comments did not make sense to me and I was asking for
>     clarification.  That was provided by both Ken and Charles' comments.
>
>     James McKenzie
>
>
>
>
> Hello Mr.McKenzie and Wine community,
>
> Happy new years.
>
> In fact, I don't try to resolve the SCSI command ioctl, to support the 
> cd-rom,
> I have just modified the CDROM_Verify(), because I thought, this function
> verify if the media is present in the device.
>
> Here my reasoning :
>
> in dll/ntdll/cdrom.c, we are in the function CDROM_DeviceIoControl().
>
> get_parent_device() is called to get the device and Wine try to open 
> the device.
>
> For what I understood,  Mac Os will create an entry object into the 
> I/O Registry,
> who represent our device, (the device exist at boot time or when it is 
> plugged).
>
> get_parent_device() will find the object, and store the name of device.
>
> After the device is found, Wine try to open it.
>
> In the case of IOCTL_*_CHECK_VERIFY request, CDROM_Verify is called, 
> In this function, we already know we have a valid device,
> in use, but if the device is present, the media is present too, we can 
> not have a file descriptor to a device, without
> media present.
>
>
Thank you for the explanation of why you did it this way.  This does 
work.  MacOSX has to be different in how it does this and that makes 
things difficult for Mac users and developers (when you step outside the 
'box' that Apple defined for us.)

James McKenzie

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20110101/3ca357c9/attachment.htm>