Messages in this thread | | | Date | Tue, 11 Jan 2005 15:06:42 -0800 | From | Matt Mackall <> | Subject | Re: [PATCH] [request for inclusion] Realtime LSM |
| |
On Tue, Jan 11, 2005 at 05:48:43PM -0500, Paul Davis wrote: > >But I'm also still not convinced this policy can't be most flexibly > >handled by a setuid helper together with the mlock rlimit. > > This has been explained several times already. > > When you run a JACK client, the user should not be required to use a > different command sequence depending on whether or not JACK is running > with RT scheduling or not. That's almost more arcane than the current > situation and is a step backwards from even 2.4, where we use > capabilities to allow JACK itself to pass on the ability to use RT > scheduling and memlock to its clients.
And that is a failure of imagination on the part of the JACK developers. Simply add a library function to libjack or whatever:
jack_make_me_important(...); /* pretty please */
A client starts at normal priority, asks jack nicely to promote it to RT, then jackd, if so configured/enabled, calls the wrapper with a PID and a priority level. The wrapper checks the UID/priority/executable name against its permission table and does sched_set{scheduler,param} if allowed.
This is nice because Jack gets to make the decisions about what the appropriate priorities for its clients are (eg they can't be higher priority than jackd, etc.) and it all gracefully falls back if the helper isn't enabled.
-- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |