Lennart Poettering wrote: > What I am saying is that the current system is too "binary": Either > you have RT sched and then for *everything*. Or you haven't, and then > you haven't got it for *anything*.
But isn't this more to do with the missing userspace support infrastructure that numerous people have pointed to than RTPRIO itself? RTPRIO itself does not imply this "all or nothing" restriction since it *can* be set on a per-application basis (given appropriate support in userspace for doing so). I also had a problem with the way PAM did the "all or nothing" approach and so I wrote set_rlimits - which grants user-specified RT privileges via RTPRIO on a user/group/program-specific basis. It's not perfect (one has to start applications via set_rlimits - eg: "set_rlimits ardour") but it works for me and didn't take all that long to write. Given this I'm sure others could come up with a workable RTPRIO-based system which included a nice user-friendly GUI configuration applet (and so forth) - set_rlimits is a proof-of-concept in a way which shows that something like this can be done. I mention this because from where I stand on the periphery it seems to me that the major issues with RTPRIO could well have been solved if the related userspace support infrastructure had been written. > For the desktop case you need something in between: RT that cannot be > misused, basically. Doing that securely is particularly hard ... Almost anything involving elevated privileges can and will be abused in time. That's why the action requires elevated privileges in the first place. Regards jonathan _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
