Patrik Stridvall <[EMAIL PROTECTED]> writes:
> Agreed. It is not unlikely that you will find some other user space
> solution using existing syscalls that are faster.
I'm afraid not, at least not one without other drawbacks; I already
spent a lot of time on this issue...
> However if you think you will get some special magical syscall, that will
> enable us to keep most of the code in userspace, included in the Linux
> kernel is very unlikely even given it will work for Wine both in theory
> and in pratice. I fear it will give unwanted side effects for other
> applications. For starters you will have a hard time designing something
> that doesn't need a scheduler supporting selective yield.
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.
> 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.
Sounds like we are in violent agreement here.
> Therefore I suggest that we doesn't try to be clever in the
> user space server but rather make it possible to cooperate
> with the kernel space server if and when available.
Provided the changes to the Wine code are extremely small, yes; but
I'm not going to change all the server interfacing code for the sake
of a "marketing gimmick".
--
Alexandre Julliard
[EMAIL PROTECTED]
