Wine kernel acceleration module?
dank at kegel.com
Sat Jan 18 19:56:27 CST 2003
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!
More information about the wine-devel