On Mon, 2009-06-22 at 20:24 +0200, Lennart Poettering wrote: > On Mon, 22.06.09 11:15, Fernando Lopez-Lezcano ([email protected]) > wrote: > > On Mon, 2009-06-22 at 15:38 +0200, Lennart Poettering wrote: > > > On Mon, 22.06.09 15:05, Fons Adriaensen ([email protected]) 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 [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
