22 Jun
2009
22 Jun
'09
1:53 p.m.
On Mon, Jun 22, 2009 at 11:34 AM, Lennart Poettering<mzynq(a)0pointer.de> wrote:
This just isn't true! We had an earlier solution that was working OK
for audio production purposes BUT the kernel folks and embedded linux
developers were not happy about it. RLIMIT_RTPRIO was the result of
some quite extensive and at times heated discussion about how to
replace the old mechanism (based on kernel "capabilities" which have
now mostly gone away) with something else that would work for everyone
that had a stake in the outcome.
What exactly are you asking for as "user-space
infrastructure"? Some
easy to reach UI that will allow you to make yourself a member of some
group? This is unlikely to happen. At least not from the desktop
camp.
Well, this is precisely what was imagined when RLIMIT_RTPRIO was added
to the kernel. Even by Ingo :) And no, you don't need to be a member
of a group - limits.conf can grant access on a per-user basis.
What I mean by infrastructure are tools to make RLIMIT_RTPRIO settings
easily configurable by the user. Its still not clear to me how this
works in the case of RTKit either.
Are you
suggesting that the original decision to focus on
RLIMIT_RTPRIO was a mistake that didn't take "the reality of what
mainstream distros will do" into account?
Yes. I guess you can say that. Although I wouldn't call it a
"mistake". RLIMIT_RTPRIO was added with audio production in
mind. However, as soon as we want to make RT available
out-of-the-box
RLIMIT_RTPRIO just doesn't cut it.
I'm sorry, I'm still not grasping the idea. Or maybe I am. You're
arguing that because we (will likely) have an RT-sched reset-on-fork
flag, that its now safe to grant RT scheduling permission by default?
First of all, I would dispute that this makes it "safe" in the sense
you want it to. By this I mean that although theoretically a clone
bomb would be stoppable with a kill(2) call, practically speaking the
machine would be rendered unusable by a suitable clone bomb attack.
That is - without the very things that you say we can't provide right
now - watchdogs, resource reservation scheduling (not isochronous),
and more. Secondly, if this flag is all that is needed to make it safe
to grant RT scheduling by default, why is RTKit needed at all?
Finally, you seem to continue assuming that SCHED_RR is the only
scheduling class of interest, which is by no means settled among the
various communities that use RT scheduling.