Wine kernel acceleration module?

[Gavriel State]

Dan Kegel wrote:
> Brian Vincent (C) wrote:
> 
>> This issue has been discussed several times.  If you
>> dig in the WWN archives you'll find mentions of it
>> going back a few years.  Much more interesting was
>> this post:
>>
>> http://www.winehq.com/hypermail/wine-devel/2002/12/0550.html
>>
>> The approach is a shared memory wineserver.
> 
> I beg to differ.  IMHO the kernel module approach
> is the best.  The PEACE team, for instance, is
> going this route in their implementation of win32
> on BSD.

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.
We spent some time on that as well before working on the ShmServer approach.

With a kernel module approach, hosting multiple wineserver environments
becomes more difficult.  A kernel module also brings with it a number of
packaging issues, and would require significant work to be moved to
non-Linux OSes.  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.  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.

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.

Take care,
  -Gav

-- 
Gavriel State, CEO & CTO
TransGaming Technologies Inc.
gav at transgaming.com
http://www.transgaming.com/

Let the games begin