The Linux audio development community has a longstanding problem: many
audio applications require very short latencies to avoid losing data, but
the Linux kernel makes it hard to get the sort of response times needed.
Over time, the audio hackers have developed a solution which works
reasonably well for them, and which they would like to see merged into the
mainline kernel. There has been strong opposition, however, leaving the
audio community feeling, once again, that its needs are being passed over by
the kernel developers.
The code in question is the realtime security module, which was covered briefly here last September. This
module, when loaded, makes a simple change to the Linux protection
mechanism: any process running with a designated group ID is given the
CAP_SYS_NICE, CAP_IPC_LOCK, and CAP_SYS_RESOURCE
capabilities. Thus, any user who has membership in the special group can
raise priorities, lock pages into physical memory, and exceed resource
limits. With these capabilities, a suitably aware audio application can
ensure that it will be able to respond to events within the required time.
A couple of objections have been raised to the inclusion of the realtime
module. One is that it is a specialized hack for a specific set of users
which has no place in a general-purpose kernel. The GID-based mechanism is
seen as being ugly and hard to administer in the long term. A few kernel
hackers have been quite vocal in their opinion that, until these issues
have been addressed, this module should not be merged. They have been less
vocal, however, on just how audio users should satisfy their needs without
offending the sensibilities of the kernel community.
Nonetheless, some progress has been made. The memory locking issue has
been solved via the new resource limits which were added in 2.6.9. By
setting the limits appropriately, a system administrator can allow
otherwise unprivileged users to lock a bounded number of pages into
physical memory. A bit of PAM configuration work should suffice to deal
with that part of the problem.
The other issue, however, is response time from the CPU scheduler. Ingo
Molnar has noted that the kernel's handling
of regular "nice" levels is much improved in 2.6.10. Audio hacker Jack
O'Quin checked it out and found that things
had improved, though the maximum response time was still far worse than can
be had by running in the SCHED_FIFO class. The reasons for this
behavior are still being investigated; interference from high-priority
kernel threads may be part of the problem. Even if the response
were adequate, however, raising priorities is still a privileged operation.
That issue could, perhaps, be addressed via yet another resource limit
which would allow individual users to raise their priorities within an
administrator-set of bounds. If the remaining response time issues could be
addressed, this new limit could be part of the overall solution, though it
would take some time for updated utilities to get into the hands of the
users who need them.
Another approach which has been mentioned would be to generalize the
realtime module to address a wider range of needs. If it could be set up
to hand out any set of capabilities to given users or groups, it would at
least be useful to more people. It could, for example, replace the current group-based hack which gives access
to the "hugetlb" mechanism. It would still be setting policies in the
kernel by way of user and group IDs, which is not a popular idea, but it
would not be quite the niche tool that it is now. A first pass at such a
module has been posted by Olaf Dietsche; it
takes an interesting approach by having much of the relevant information
stored in the form of group ownership on sysfs attributes.
A more comprehensive solution would be to make capabilities work properly.
After all, that is what capabilities are supposed to be for: to allow
precisely-defined bits of privilege to be granted in the situations where
they are needed. The problems there are that Linux capabilities are currently
broken, fixing them is a tricky job that nobody seems to want to take
on at the moment, and, in any case, administering a truly capability-based
system is an exercise in complexity. Capabilities seem unlikely to be part
of the solution anytime soon.
One interesting aspect of the discussion is what has not been
mentioned. SELinux should be able to solve this problem; it exists to
provide ultimate control over what every user and program can do. Nobody,
however, has wanted to see what happens when musicians attempt to
administer SELinux, it would seem. The realtime preemption work has also
been strangely absent from the discussion - and from the kernel mailing
lists in general.
As of this writing, no real solution seems to have been found. There are
enough kernel hackers sympathetic to the needs of audio hackers, however,
that some sort of resolution should be possible. Linux should be the
ultimate playground for audio developers; it would be a shame if the kernel
continued to get in their way. (For more background, see this history of the realtime LSM by Jack
to post comments)