https://bugs.winehq.org/show_bug.cgi?id=39569
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12@gmail.com
--- Comment #3 from Zebediah Figura z.figura12@gmail.com --- There are a number of difficulties I see in solving this:
(1) We currently rely on mountmgr to create devices, including determining the device type. But we run into a bootstrapping problem, because various components (including wineboot) need to access the C: and Z: drives before mountmgr is even started.
One way to solve this is to retain the current symlinks and drive resolution logic from ntdll, and fall back to it if creating a device on the server side fails.
Another way to solve this is to create at least the C and Z volumes from the server side. Probably in that case we'd want the server to have a server-side "volume" device object, that mountmgr creates? Or maybe mountmgr should somehow replace the drives or the symlinks once it's started?
(2) Generally, retaining current performance. While feeding file operations directly through to mountmgr as if it were any other NT kernel driver would work fine, the overhead is pretty significant (RPC to the server for each file operation, and another essentially two RPCs from mountmgr to the server.) This can be improved dramatically by keeping unix fds cached the same way we do now (I guess we'd want a way for mountmgr to tell the server to associate a given unix fd with its device file?) but that doesn't help create or close requests (which require a server call anyway, but at least it was just one server call).
The most obvious way to solve this is, as was partially proposed to fix problem (1), to have the server keep track of volumes specially. In that case I'm not even sure mountmgr would create volume devices directly, but rather it would probably go through some "create_volume" server request, passing through the mount point.