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 :-)
[...]
- 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.