RFC: ntdll: Implement CDROM_GetInterfaceInfo() on Mac OS (try 2)

[Charles Davis]

Alexandre Julliard wrote:
> Charles Davis <cdavis at mymail.mines.edu> writes:
> 
>> Alexandre Julliard wrote:
>>> Charles Davis <cdavis at mymail.mines.edu> writes:
>>>
>>>> Or, maybe not. I could be totally wrong about that. Maybe what you
>>>> really want is for me to get an FD from mountmgr so I can talk to it at
>>>> will. I don't know.
>>>>
>>>> We can even add the FD to mountmgr's run loop (via a CFFileDescriptor
>>>> object), or if you prefer, we can do the traditional select() or poll()
>>>> loop. (But why spawn another thread just for that?)
>>> No, nothing of the kind. You wouldn't talk to mountmgr at all. All you
>>> would do is do an ioctl on an NT device, and that would magically get
>>> routed to the right place. Look at how IOCTL_STORAGE_GET_DEVICE_NUMBER
>>> is handled for a hard disk device for instance.
>>>
>> OK, now I'm thoroughly confused. What's the purpose of getting an FD
>> from mountmgr in all this? And what the hell am I trying to do in the
>> first place?! (Sorry for the language, but I just don't understand what
>> you're getting at.)
> 
> You don't need an fd for that specific ioctl, if you implement it in
> mountmgr. You need it for the other ones that are still done on the
> client side, and for normal I/O calls.
> 
OK, so let me see if I have all this straight: you want me to implement
some wine-specific IOCTLs in mountmgr that return the SCSI address and
anything else I can think of tha belongs in mountmgr. You also say that,
if necessary, I should pass an FD from mountmgr back to the caller
(ntdll) via a UNIX-domain socket, but that I don't have to for this
particular IOCTL. You also want me to move getting the parent device
into mountmgr (where I think it belongs, frankly), which is an instance
where I'd need to pass an FD back to ntdll. Do I have all this right?