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 [EMAIL PROTECTED] http://fgouget.free.fr/ Avoid the Gates of Hell - use Linux.