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

On Mon, 2009-06-22 at 20:24 +0200, Lennart Poettering wrote:
> On Mon, 22.06.09 11:15, Fernando Lopez-Lezcano (nando@email-addr-hidden) wrote:
> > On Mon, 2009-06-22 at 15:38 +0200, Lennart Poettering wrote:
> > > On Mon, 22.06.09 15:05, Fons Adriaensen (fons@email-addr-hidden) wrote:
> > > > On Mon, Jun 22, 2009 at 09:24:24AM +0100, Bob Ham wrote:
> > > >
> > > > > There's something wrong here.
> > > >
> > > > There is a lot wrong here.
> > > >
> > > > * Question: is the 'demoting' of RT-threads applied only to RT
> > > > threads granted by this daeomon, or does it apply to all, including
> > > > those created by processes running as root ? In the latter case this
> > > > system is not only broken, but should be classified as malware.
> > >
> > > Is that so?
> > >
> > > It can do both. resetting all is the default.
> >
> > 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?

> Even if some folks seem to believe it, I am not replacing anything
> existing, shoving down their throats something they didn't need
> before. All I do is adding something new, that helps a few desktopish
> cases and can be integrated into various applications very easily and
> with only minimal impact on dependencies, and is only used as fallback
> if nothing else is configured.

I understand that as well. If I may disagree, the long term implication
of rtkit is not just helping a few desktopish cases. It may be why it
was written. But if successful, it will be the only way a distribution
will grant !SCHED_OTHER out of the box, so it will affect anything that
wants to run !SCHED_OTHER out of the box in that distribution (say,
Fedora), including, for example, jack & friends. Thus my concerns and
questions.

(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).

> Really, I am doing my best to ease adoptions for those interested.
>
> > (I assume, for example, that it would not under any circumstances reset
> > the scheduler of the kernel interrupt processes in an rt patched
> > kernel!!)
>
> By default it only ever looks at non-root processes.

Thanks...
Sorry but that is not what I understood from your answer. Fons asked:

> * Question: is the 'demoting' of RT-threads applied only to RT
> threads granted by this daeomon, or does it apply to all, including
> those created by processes running as root ?

Note the part about "including those created by processes running as
root". Your answer:

> It can do both. resetting all is the default.

To my eyes "resetting all" would mean to _include_ processes running as
root, thus my remark.

-- Fernando

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Tue Jun 23 00:15:03 2009