22 Jun
2009
22 Jun
'09
4:24 p.m.
On Mon, 22.06.09 11:15, Fernando Lopez-Lezcano (nando(a)ccrma.Stanford.EDU) wrote:
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.
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.
Really, I am doing my best to ease adoptions for those interested.
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:
Is that so?
It can do both. resetting all is the default. 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. (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.
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/ GnuPG 0x1A015CC4