On Mon, 2009-06-22 at 14:18 -0700, Fernando Lopez-Lezcano wrote: > On Mon, 2009-06-22 at 22:04 +0200, Lennart Poettering wrote: > > On Mon, 22.06.09 12:51, Fernando Lopez-Lezcano (na...@ccrma.stanford.edu) > > wrote: > > > > > Good question. > > > > > > > > > > Why is it resetting all the default, even processes with rt privileges > > > > > not granted by RealtimeKit? Isn't rtkit supposed to be the only > > > > > authorized way to access schedulers other that SCHED_OTHER by non-root > > > > > users? > > > > > > > > rtkit doesn't need to be the exclusive consumer of the kernel RT > > > > interfaces. RLIMIT_RTPRIO is another supported mechanism that > > > > continues to work. > > > > > > Maybe I did not frame the question correctly: if the system has been > > > configured on purpose by the administrator to grant !SCHED_OTHER by > > > using RLIMIT_RTPRIO, why does rtkit have to mess with processes that it > > > did not grant privileges to? > > > > rtkit is bus activated. It's only active when it is used. The > > distinction between demoting all and demoting only the 'known' > > processes is hence mostly theoretical. > > No, it is absolutely practical. > > > I picked "demoting all" as the default since it 'felt' more > > secure. Dunno. > > What is rtkit assuming with that behavior? That any non-root process > that it did not authorize is fair game for it to meddle with. That is an > incorrect assumption.
I think I may be misunderstanding something. Or I'm just SSSLLLLOOOOWWWW... You wrote yesterday: > rtkit only comes into play as last resort when rt is cannot otherwise > be required (at least if developers follow my recommendations from the > README). If the supervised realtime sched that rtkit gives you isn't > good enough, then simply give your application unsupervised RT by > means of RLIMIT_RTPRIO or CAP_SYS_NICE or something suchlike. If rtkit would demote all processes when triggered, regardless of whether rtkit granted the privileges or not then I can't really bypass it, it is always there defining policy. -- Fernando _______________________________________________ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev