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

[Kjetil Svalastog Matheussen]

On Tue, 24 Nov 2003, Jack O'Quin wrote:

>
> 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?
>
Cant think of any.

>   (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.
>
Yes, I noticed that problem as well.

> 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.

I thought about hacking together those additions after it was posted,
but soon after Robert posted a module that seemed to solve the problem
in a much better way.
Whats the status of that patch, and does it only work with 2.6.

And in  case it only works with 2.6, can't a similar module be made for
2.4? I know it can, because we can just copy the code in the sys_setched
and sys_mlockall functions into the module.


--