Wine kernel acceleration module?

[Francois Gouget]

On Sun, 19 Jan 2003, Shachar Shemesh wrote:

> Francois Gouget wrote:
>
> >So you're better of with the kernel module if the bug is in the
> >application, and you're better of with shm if the bug is in the server.
> >Then it's a matter of which one is more likely.
> >
> I'm not in front of the sources at the moment. How big is the wineserver
> at the moment?
>
> If it's rather big (and I rather suspect it is), then it seems obvious
> which one is more likely.

$ find server -name "*.[ch]" | xargs cat | wc -l
  22452
 $ find . -name "*.[ch]" | xargs cat | wc -l
1237362
$ find dlls files graphics if1632 library loader memory misc miscemu
msdos objects ole relay32 scheduler win32 windows -name "*.[ch]" | xargs
cat | wc -l
 861271

So depending how you count the server represents between 1.8% and 2.6%
of the Wine code. That's far from being a big portion of Wine.


> The windows apps are released apps that were working on Windows NT.
> The wineserver, on the other hand, is a piece of Alpha software that
> has not seen too much pounding into. I think that a bug in the server
> is MUCH MUCH MUCH more likely to happen.

That's not supported by the above, and especially not by experience. How
often have you seen applications crash in Wine? Me i see them crash
every day (but of course being a Wine developper I am only interested by
applications that crash). But most of the time it is the application
that crashed, not the Wine server. In fact, I have not had a Wine server
crash in at least a month.

The thing is that yes, applications may be stable when they run on
Windows NT, but they are running in Wine and make heavy use of the Wine
libraries (~70% of the code). And in fact, I forgot the most important
line in my table. Here it is duely corrected:

                  | Current       | Kernel         | Shm
------------------+---------------+----------------+--------------------
Bug in a Wine     | Process       | Process        | Wine
library           |               |                |
------------------+---------------+----------------+--------------------
Bug in a Windows  | Process       | Process        | Wine
application       |               |                |
------------------+---------------+----------------+--------------------
Bug in the server | Wine          | Machine        | Wine


> I think the best approach is a hybrid one. We have a kernel module that
> does only the bare minimum required in the kernel. Everything else is
> done using user-mode processes.

There I completely agree with you. Only the speed-critical items should
be handled by the kernel module. Ideally it would only provide a couple
of concepts (e.g. HANDLE <-> fd mapping) that would allow us to have
good performance while only doing a minimum in the kernel (e.g. not
doing the Windows <-> Unix path conversions). But that's probably easier
said than done and the above handle and file descriptor example should
be taken more as an illustration than as a hard and fast recommendation
on the way to do it :-)


[...]
>    4. Rebooting wine does not require rebooting the kernel (machine), or
>       even unloading and reloading the kernel module.

Whatever the scenario I am not sure there is anything forcing us to
restart the Wine server for 'rebooting' the Wine environment.  The only
thing requiring a Wine server restart would be upgrades. But even a with
a kernel module, unloading and reloading the module should be enough.


-- 
Francois Gouget         fgouget at free.fr        http://fgouget.free.fr/
                     Avoid the Gates of Hell - use Linux.