Re: Wine performance improvement

[임은지]

Dan Kegel wrote:
> Interesting!    Clearly a long ways off from production-ready, but
> it's fun to see somebody trying this.
>
> A few notes:
>
> Please clean up the patch a bit to remove lines like this:
> +//FIXME("handle : %ld \n", handle);
> and extra files like
> dlls/ws2_32/tests/test.sh
>
> Please avoid hand-editing
> include/wine/server_protocol.h
> The start of the file even says:
>  * This file is automatically generated; DO NO EDIT!
>  * Edit server/protocol.def instead and re-run tools/make_requests
>
> Please switch to plain text for future posts.  It's very
> hard to read in the archive; see
> http://www.winehq.org/pipermail/wine-devel/2009-December/080394.html
>
> Please identify the author(s) of the new code for copyright purposes,
> and ensure they agree to licensing their code under the LGPL (for Wine)
> and GPL (for Linux kernel).
>
> I'm sure other people will have more to say.

Thank you for your comments.
I will cleanup the patch as you suggested and send it.

Wine performance improvement

[Stefan Dösinger]

Am 09.12.2009 um 09:36 schrieb 임은지:
> Thank you for your comments.
> I will cleanup the patch as you suggested and send it.

Did you contact the kernel maintainers regarding the kernel side of your changes? I think including the Wine patch doesn't make sense until the kernel developers accept the kernel side of it.

Wine performance improvement

[Wolfram Sang]

Stefan Dösinger wrote:
> Am 09.12.2009 um 09:36 schrieb 임은지:
> > Thank you for your comments. I will cleanup the patch as you
> > suggested and send it.
>
> Did you contact the kernel maintainers regarding the kernel side of
> your changes? I think including the Wine patch doesn't make sense
> until the kernel developers accept the kernel side of it.

In the current form, this is unlikely. There are a number of formal 
issues alone:

- needs to be based on a somewhat recent version of the kernel
- too much #ifdef
- just one big patch
- too much debug output
- too much code commented out
- commenting not consistent (//)

The latter three can be easily worked out, of course. The others are a 
bit more troublesome, but are major show-stoppers nevertheless.

Also, adding syscalls is a very, very sensitive area. You really need a 
gallore of good arguments for that. IMHO I have doubts here, because the 
rest of the code looks also a bit intrusive to me (i.e. patching 
fork|sched.c).

Then again, was it really the aim to send this upstream? I didn't get 
the impression when I read the original posting, more like "We did 
something interesting. Maybe you want to try it?"

Kind regards,

Wolfram