Subject: [linux-audio-dev] Re: POSIX caps/realtime/root processes
From: Jack O'Quin (joq_AT_io.com)
Date: Tue Nov 25 2003 - 05:49:16 EET
Kjetil Svalastog Matheussen <k.s.matheussen_AT_notam02.no> writes:
> > I couldn't wait til you found it, so I wrote one from scratch instead. :)
> > The url below point to a hackish patch againt 2.4.23-rc1, and yes, it is
> > very simple. Works by setting /proc/sys/kernel/setschedandmlock to 1.
> > http://www.notam02.no/arkiv/src/schedmlockpatch-2.4.23-rc1
Fernando Pablo Lopez-Lezcano <nando_AT_ccrma.stanford.edu> writes:
> Hey! Good! I'm very tempted to add it to the Planet CCRMA kernels right
> away :-)
>
> Has it seen much testing? Not that something so simple would require a
> lot of testing, of course. I'm trying to think of potential problems
> (over the use of capabilities) and can't think of anything. The only
> that would occur to me is that access to SCHED_FIFO would be more
> universal whereas with capabilities, programs like givertcap or
> jackstart are required.
I finally got around to testing Kjetil's patch (backported to 2.4.19).
It basically works, but I found a couple of problems...
(1) The patch allows SCHED_FIFO but not SCHED_RR. This makes
PortAudio V18 fail. That looks trivial to fix. Is there any reason
to allow one realtime scheduling policy and not the other?
(2) I can start `jackd -R' as a normal user, but its clients fail to
connect. This looks like a problem in the capabilities_workaround
logic of jack_start_thread(). The test fails because the engine has
the `realtime' flag set, but not `has_capabilities'. I hacked a
patch for that test and now it works. I need to figure out if that
is the correct fix before committing it to CVS, though.
I did this as a baseline before adding the `realtimegroup' logic we
discussed last week. I think I'll attempt that next, after fixing the
SCHED_RR omission.
-- joq
This archive was generated by hypermail 2b28 : Tue Nov 25 2003 - 05:48:42 EET