Hey guys,
let me just try and be constructive here...
as far as I understand, RLIMIT_RTPRIO was decided as a solution about three
years ago, but lacks a userspace interface.
From the post below, I understand that there is already a small app made by
Jonathan Woithe that helps out in this aspect,
and that that could be expanded/adapted to do the job properly.
It seems that that would be a much more useful approach than adopting this
apparently controversial rtkit, which as I understand, also only works with
kernels newer than what anyone really has these days.
So it seems to me that if we put our thoughts together, figure out what we'd
want the userspace interface to be like for RLIMIT_RTPRIO, and get a few of us
to code this up, this would benefit a lot more people, as it would be
backwards compatible for kernels up to three years old. (That might be even a
previous Debian stable. :) ).
Plus, if I understand correctly, it wouldn't require changes to how things are
coded in audio programs, which would make it backwards compatible with all of
these cool apps, even the ones that are not so actively maintained anymore.
If we do this right, then it'll surely reach the main distros somehow :)
sincerely,
Marije
(who would just like to have easily configurable rt-stuff, with some readable
guides on how to do it properly).
On Monday 22 June 2009 19:44:01 Jonathan Woithe wrote:
> 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.
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Mon, 22 Jun 2009 20:48:37 -0400
This archive was generated by hypermail 2.1.8 : Tue Jun 23 2009 - 04:15:09 EEST