On Thursday 27 July 2006 06:10, Mike Hearn wrote:
On Thu, 27 Jul 2006 02:18:49 -0700, Chris wrote:
Or if you still don't want something like that merged in, I'd like to alert the author of that patch that it doesn't require root privs to work. It just needs a non-0 value for RLIMIT_RTPRIO (ulimit -r).
Thanks for the heads up. I'll let Alexandre comment on the other stuff but I wanted the patch to work out of the box for all users, with no configuration necessary.
It does. You don't really have to change anything. Only thing that'll happen is the setup_security function won't do anything, but the set_thread_priority funciton would still work. It's just a difference of setting the suid root bit and re-chown'ing /tmp/.wine-* all the time, or setting a non-zero RLIMIT_RTPRIO value for the user. I just think it'd be nice to let users of that patch know they don't need to run Wine with root privs if they don't want.
I don't see any way to resolve this issue satisfactorily. Windows apps require hard real time support, the kernel won't give it to us without privileged access, Alexandre doesn't want to let Windows apps do that.
I personally don't see what's wrong with letting the user decide. Without setting the suid root bit, Wine won't get any more privileges than any other Linux app run by the same user would get. Wine would just take advantage of the capabilities of a new-ish kernel feature (one that was explicitly added in, mind you; it's not a side effect or unforseen consequence) for the exact reason it was made.. to allow user space apps to get real-time priority, as defined by the user's system settings. It wouldn't be automatic, so Wine couldn't deadlock the system without the user explicitly setting the resource limit. It's exactly what Wine would need, so why not use it?