Alexandre Julliard <[EMAIL PROTECTED]> wrote:
> I told you what I wanted: basically a pipe with slightly different
> semantics; no need to touch the scheduler for that. It should be
> pretty easy to code for an experienced kernel hacker (which I'm not),
> and then we can run benchmarks and see if the idea has any merit at
> all.
Perhaps you'd consider taking a look at the RPC mechanism that I designed and
mostly implemented... It currently passes an address from the client to the
server and accepts an integer and an error number back. What I haven't had
time to write yet are the ptrace-style read/write functions that will allow
the server to gain access to the client's memory space. An extra pair of
functions could also be provided to paste fd's between the client and server.
Patrik Stridvall <[EMAIL PROTECTED]> wrote:
> Seriously, as I said above, I consider a Linux kernel Wine server
> nothing more than a marketting gimmick. I would very much prefer
> the user space Wine server to be maintainable and robust rather
> than fast. 99.99% of all application that are likely to be run
> under Wine will not care if mutexes are 900% slower as long as
> they have the correct semantics.
What I'm most concerned about with wine is the fact that every time a file
operation is issued, the client makes a call to the server to convert the
Win32 file handle into a UNIX fd (via sendmsg/recvmsg), which gets used once
and then discarded.
I've seen programs that do a lot of I/O (for instance PVCS) hammer the server
lots with requests for file handle conversion, and so they run quite a bit
slower on Linux than on Windows.
I do also wonder about the server running out of fd slots, but I don't think
that is too much of a problem.
Of course the biggest reason for doing this is the technical challenge... and
of course proving to the Windows nutters around that Linux can do Windows
system calls faster than Windows itself *grin*.
David Howells
