Gavriel State wrote:
Each approach has its own merits - you'll note in our paper that we also posted sources and design documentation for KWine, an alternative wineserver kernel module design that keeps Win32 HANDLE objects in a Linux file system.
Yeah, thanks for posting that. I didn't have a chance to read the code, but I hope to sometime.
With a kernel module approach, hosting multiple wineserver environments becomes more difficult.
Yes, but I think that's a red herring. We don't need multiple wineserver environments, really, except in the same way that we need multiple linux environments (e.g. with chroot jails).
A kernel module also brings with it a number of packaging issues, and would require significant work to be moved to non-Linux OSes.
Very much so.
Lastly, the kernel module approach requires an all-at-once rewrite of the wineserver interactions, whereas the ShmServer can be implemented on a call-by-call basis.
Is that really true? There might be some way of bringing in the kernel module incrementally. You'd know better than me, but still...
About the only thing a kernel module would have over the ShmServer on the performance front would be the ability to do PE relocation fixups at page-in time, like Windows does. The value of that feature is limited, IMHO. A kernel module may also have some benefits from the security perspective.
I suspect the kernel module would be better protected from wild memory accesses by the user processes as well.
Regardless of which one is better, it would be nice to see more interest in this topic from other developers. If anyone else is interested in collaborating on the ShmServer or kernel module approaches, that would be great.
Indeed. Thanks for your great work! - Dan