Re: ntdll/cdrom : implement CDROM_Verify to work on Mac Os
maury loïc <lmaury(a)gmail.com> wrote:
Hello Ken and the Wine community,
Please bottom post or post directly to a question. Please do not top post.
On Thu, Dec 30, 2010 at 12:51 PM, Ken Thomases <ken(a)codeweavers.com> wrote:
Hi Loïc,
On Dec 30, 2010, at 4:20 AM, maury loïc wrote:
it's my first patch, and it implement the CDROM_Verify() to work on Mac Os.
I think most people are going to need more explanation for why this is a legitimate way to implement this function on Mac OS X. :)
Cheers, Ken
For what i understood, The function CDROM_Verify(), verify if the media is present on the device, and Wine try to open the device(in Mac Os case), before call the CDROM_Verify().
But Mac Os manage the device differently from the other Os. It create the device, only if the media is already present. Logically, CDROM_Verify() return success, because when we are in CDROM_Verify() we already know the device.
What do you think ?
This has been critically examined by several people and if the solution were this simple it would have been put in place a long time ago. Charles Davis has spend over a year looking at how to implement CDROM functionality for MacOSX. So, here is my question: How can the community be 100% certain that: 1. The device has EXACTLY the same name on every available MacOSX installation? 2. How can you be 100% certain that if the 'device' exists that the code will end up in CDROM_Verify()? James McKenzie (Another Mac User/Wine Tester.)
On Dec 30, 2010, at 9:36 AM, James McKenzie wrote:
This has been critically examined by several people and if the solution were this simple it would have been put in place a long time ago. Charles Davis has spend over a year looking at how to implement CDROM functionality for MacOSX.
Rather than arguing in sweeping generalizations, can we confine ourselves to the technical specifics of this particular case, please? When you say "this has been ... examined", are you referring specifically to CDROM_Verify()?
So, here is my question: How can the community be 100% certain that:
1. The device has EXACTLY the same name on every available MacOSX installation?
What does the device name have to do with anything? Do you think that Loïc's patch somehow contains an implicit dependence on device names? If so, why?
2. How can you be 100% certain that if the 'device' exists that the code will end up in CDROM_Verify()?
Why does that matter? The question is, under what circumstances does it end up in CDROM_Verify()? What is the right behavior of CDROM_Verify() and how would that be implemented on Mac OS X? Can you explain which aspect of CDROM_Verify()'s behavior is not properly implemented by Loïc's patch? Regards, Ken
On Dec 31, 2010, at 1:38 PM, Ken Thomases wrote:
Why does that matter? The question is, under what circumstances does it end up in CDROM_Verify()? What is the right behavior of CDROM_Verify() and how would that be implemented on Mac OS X?
I should add that this patch seem correct to me. It couldn't hurt to get Charles Davis's input, of course. CDROM_Verify() is called when CDROM_DeviceIoControl() gets a IOCTL_*_CHECK_VERIFY request. CDROM_DeviceIoControl() is only called (from NtDeviceIoControlFile()) for the appropriate type of device and that's further verified (on Mac OS X) by the call to get_parent_device(). 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. Which is basically what Loïc said. :) -Ken
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." 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.
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. Chip
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
On Sat, Jan 1, 2011 at 2:22 AM, James McKenzie <jjmckenzie51(a)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. merci Loïc
On 1/1/11 4:07 AM, maury loïc wrote:
On Sat, Jan 1, 2011 at 2:22 AM, James McKenzie <jjmckenzie51(a)earthlink.net <mailto:jjmckenzie51(a)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
participants (5)
-
Charles Davis -
James McKenzie -
James Mckenzie
-
Ken Thomases -
maury loïc