22 Jun
2009
22 Jun
'09
5:51 p.m.
On Mon, 2009-06-22 at 20:24 +0200, Lennart Poettering wrote:
On Mon, 22.06.09 11:15, Fernando Lopez-Lezcano
(nando(a)ccrma.Stanford.EDU) wrote:
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?
On Mon, 2009-06-22 at 15:38 +0200, Lennart
Poettering wrote:
rtkit doesn't need to be the exclusive consumer of the kernel RT
interfaces. RLIMIT_RTPRIO is another supported mechanism that
continues to work. On Mon, 22.06.09 15:05, Fons Adriaensen
(fons(a)kokkinizita.net) 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? 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. 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.
Thanks...
Sorry but that is not what I understood from your answer. Fons asked:
(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. * 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