On 02/25/2011 04:29 PM, Paul Davis wrote: > On Fri, Feb 25, 2011 at 10:23 AM, Olivier Guilyardi <[email protected]> wrote: > >> 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.
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. > 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 _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
