On Sat, 18 Jan 2003, Gavriel State wrote: [...]
A kernel module may also have some benefits from the security perspective.
I am not sure a kernel module would be inherently better from a security point of vue: after all, the same module would handle all the users on the system. So there would be more risk that a user gains access to data he should not have access to. On the other hand it may also make it possible to implement CreateProcessAsUser&co... not that they are used much though.
Anyway, when compared to the shared memory server it seems to me that the main advantage of a kernel module is stability. It is my understanding (correct me if I'm wrong) that with the shared memory approach, a buggy (or malicious) Wine/Winelib application could crash all other Wine/Winelib applications using that server (at least only one user would be affected). That seems like a significant drawback.
In either case though, to me it seems the two biggest obstacles are maintenance and compatibility: * if either approach requires duplicating (too much of) the server code, then the big question is whether there will be enough people interested for that alternate implementation to be maintained. * there are still signifcant changes in the server code. In my understanding there are still a number of things that are currently managed on a per-process basis and that should be managed by the server instead. Being able to easily switch from one implementation to another seems important to me. But this kind of compatibility requires that they remain in sync... that sort of brings us back to maintenance.