Kjetil Svalastog Matheussen <k.s.matheussen(a)notam02.no> writes: Fernando Pablo Lopez-Lezcano <nando(a)ccrma.stanford.edu> writes: 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

Kjetil Svalastog Matheussen <k.s.matheussen(a)notam02.no> writes: The Linux Security Module (LSM) interface is a standard part of 2.6. There actually is a backport of the security modules patch to 2.4 on the NSA site for SELinux. But, it is quite large and I doubt many people would want to apply it for running realtime audio. Your small patch is probably safer and more secure. So, my feeling is that the best approach is... (1) LSM for 2.6. This is something we might ask multimedia distributions to distribute, enabling an optional turn-key solution for realtime audio. (2) An interface-compatible variant of your patch for 2.4. This would probably only be available for do-it-yourself kernel builders and via special-purpose distributions like Planet CCRMA. Basically, this is for people who are currently using capabilities and need to continue using 2.4 for a while. I don't see it as a long-term solution. Most of those people will probably migrate to 2.6 fairly quickly. Some applications may want to test whether the `kernel/realtime*' variables exist. At least they would work the same, when present. Generally, the best way for an application to test their privileges is by directly trying the desired system call to see if it works or returns EPERM. In the face of capabilities patches, your patch, optional LSM features, and users running as `root', this is the only reasonable thing to do. Some programs test for (geteuid() == 0), which was already a mistake. I intend to continue experimenting along these lines until I prove to myself that all this really works and is useful. So, far it looks encouraging. Regards, -- joq

On Tue, 25 Nov 2003, Jack O'Quin wrote: I still like a module idea though. I dont see the point of patching the kernel with the security module interface, except for the security. What I would like, though, is: -A module that does not require any patches to the kernel. -A module that provides some sort of give_me_realtime(int pri) function, which can be called without being root or have capabilities. -This give_me_realtime_or_something function sets SCHED_FIFO priority and calls mlockall() and sets up a watchdog of some kind (shouldn't be to hard when you are inside the kernel). Why? -No patching of the kernel. -Same interface for 2.4 and 2.6, and possible other OS'es. -Simple interface for the programmer. -The module should be easy to make. Unfortunately, I dont have the time to make this module right now. --

On Wed, 26 Nov 2003, Jack O'Quin wrote: So how is the low-latency situation for 2.6? I did install 2.6 on my private machine, but was not able to get better performance than 2.4 with ll+pre (kicked out of jack-graph pretty soon with 128 frames period). Is there a trick to get better lowlatency performance with 2.6 I don't know about? --