Wine kernel acceleration module?

Dan Kegel dank at
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!
- Dan

Dan Kegel

More information about the wine-devel mailing list