25 Feb
2011
25 Feb
'11
4:54 p.m.
On 02/25/2011 04:29 PM, Paul Davis wrote:
On Fri, Feb 25, 2011 at 10:23 AM, Olivier Guilyardi
<list(a)samalyse.com> wrote:
I was only supposing the integration of ulatencyd with JACK to illustrate my
points. I was not saying that it's necessary a good idea.
But let's take JACK for example. It handles
setting up realtime scheduling
transparently when one creates a jack client. There isn't any extra step
necessary. As a supposition, could you imagine that ulatencyd integrates tightly
into JACK to provide fine-grained per-client realtime permissions?
ulatencyd is, IMHO, a complete red-herring here. it has nothing to do
with what JACK does. ulatencyd appearst to me concerned entirely with
desktop latency and the notion that the "current app" (as represented
by some form of ongoing user interaction) should be the most
responsive. this has nothing whatsoever to do with the realtime
scheduling that JACK is concerned with. specifically, what JACK does is per-thread, and more
significantly its either:
* for threads that it creates (inside libjack) AND knows that they
need to be RT
* for threads that the client specifically asks to be RT
you can't do this stuff on a per-process level.
Let me rephrase my idea.
Let's imagine that JACK runs as a privilege user, which in addition of having
realtime privileges, is also able to assign other processes to given cgroups and
adjust their sched_rt_runtime_us and sched_rt_period_us dynamically. Which is
the kind of thing which ulatencyd does IIUC.
But let's forget about ulatencyd for a second.
Let's now consider that clients runs as user(s) which do not have realtime
privileges by default, but that it's JACK which grant them such privileges and
assign them a certain CPU time share dynamically. In this scenario could also
refuse connections if it considers that there isn't enough resources.
Doesn't this make sense to a certain extent?
Wouldn't this be an improvement in regard to security?
--
Olivier