Messages in this thread |  | | Subject | Re: [RFC] Wine speedup through kernel module | Date | Tue, 19 Sep 2000 16:20:27 +0100 | From | David Howells <> |
| |
Daniel Pittman <daniel@rimspace.net> wrote: > Hrm. It would seem more sensible to me that the registry, like the GDI, > live outside the kernel. This would have some cost in terms of > performance, I admit, but I don't think it's significant enough to care. > > This is, I confess, based on my personal experience with Win32 > development and may not represent the real state of affairs for all > developers. > > Having registry access be performance critical or for large data is also > against the MicroSoft best practice for software, which makes the costs > lower - no multiple calls to ship large quantities of data. :) > > Anyway, why did you see the need for the registry stubs in this case, if > I may ask?
Firstly, in wine the registry is handled by the wineserver process. This means it can be shared between all the wine processes running for a particular used. So when wine wants to access the registry, it has to do an RPC call to the wineserver (sending a request across a UNIX socket and then, I think, a bit of ptrace()'ing to get at the data). This provides a hopefully more suitable RPC mechanism.
Secondly, the client (wine) just has to issue a syscall that looks exactly like a Win32 registry function, how it is handled is hidden by the kernel.
Thirdly, registry functions should issue system handles, as is done on Windows. If system handles move into the kernel, then registry handles should do too. This also means registry change notifications can be implemented by system handles that WaitFor*() functions can deal with.
> Well... wont the GDI calls be RPC anyway - specifically, across the X11 > pipe?
Yes, but if I implement them to go to a GDI server, which then talks X11 out the back, that's two lots of RPC calls.
However, what I said about system handles and the registry, may also apply to GDI objects.
> In any case, I would have expected (personally, from assumptions) that > the GDI would live inside the process space and pay the same cost as > existing X11 applications to do it's display.
Yes, that is my current plan.
> I can't see any sensible reason for implementing anything extra in the > kernel to support it. Now, adding an X11 protocol extension to make some > of the Win32 stuff work better...
Now there's an idea... Have the local X server as an RPC server, handling wine GDI calls directly *grin*. Then I could hide all the GDI stuff behind syscall stubs in the same way. This would allow me to implement a lot of the NT Native API.
David Howells - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |