[linux-audio-dev] Re: POSIX caps/realtime/root processes

[Jack O'Quin]

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