Alexandre Julliard wrote:
Charles Davis cdavis@mymail.mines.edu writes:
Alexandre Julliard wrote:
Charles Davis cdavis@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?