[LAD] [ANNOUNCE] Safe real-time on the desktop by default; Desktop/audio RT developers, read this!

Lennart Poettering mzynq at 0pointer.de
Mon Jun 22 20:04:13 UTC 2009


On Mon, 22.06.09 12:51, Fernando Lopez-Lezcano (nando at 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.

I picked "demoting all" as the default since it 'felt' more
secure. Dunno. If someone can offer me real-world case where this
distinction really matters, I am all ears. Otherwise I'd got for the
safe default for now.

> (yes, I understand RLIMIT_RTPRIO will still be there, the system will
> just not be configured out of the box to grant any access through that
> mechanism). 

For RLIMIT_RTPRIO nothing changes. It wasn't enabled by default in the
big distros and it wont be enabled in the future either.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4



More information about the Linux-audio-dev mailing list