Subject: [linux-audio-dev] RT scheduling, root and end users. (was: Re: [rtl] virtual memory in RTL)
From: David Olofson (david.olofson_AT_reologica.se)
Date: Thu Mar 23 2000 - 17:07:35 EET
Thu, 23 Mar 2000 yodaiken_AT_fsmlabs.com wrote:
> On Wed, Mar 22, 2000 at 06:02:24PM +0100, David Olofson wrote:
> > And as for the root privileges requirement, it has been discussed adding a
> > "real time" user group capability instead. (I'm not up to date with this,
> > though.) Running RT apps as root just for the scheduling is not all that nice in
> > production systems, especially not if they are going to run user installed
> > third-party plugins in those threads...
>
> On Linux, I think if you are going to run SCHED_RR you better either be root
> or be created by a root privelege "scheduler".
Root is a bad idea for the average user running a multimedia application, game
or whatever, as it basically turns Linux into Win95/98 without the kernel
crashes. Inexperienced users *will* (don't ask me what they're doing...) break
their systems by accidentally deleting/renaming/... files, just as they have
been doing with DOS, Win3.x and Win95/98 all the time.
Finally getting rid of this silly problem is one of the few things that
actually make Linux a better alternative for Joe Average. Getting some geek to
install the OS and say "Just use and have fun - you can't break anything
important!" is a lot better than "Uhm, you mustn't touch that dir, or that, or
any of those files... And don't fiddle with that config dialog! And..."
I don't think assuming that some "sysadmin" will install all their applications
will be sufficient for very long, unless the plan is to keep Linux out of the
mainstream desktop OS game. There are various tricks, but someone or something
directly involved has to be root at some point...
> SCHED_RR is too dangerous.
Yes, but only if applications can freeze (the user space part of) the system
indefinitely - which they can, unless there is some kind of watchdog thread or
a kernel level timeout for repeated scheduling of a single task (SCHED_RR) or
no rescheduling at all (SCHED_FIFO).
A user space watchdog could probably be realized as a daemon with two threads,
one SCHED_OTHER and one at SCHED_FIFO, highest priority, that try to communicate
regularly. Upon repeated failure to get the SCHED_OTHER thread to run, the
SCHED_FIFO thread (driven by some timer or other kernel "time base") would kill
all processes with SCHED_FIFO and SCHED_RR threads belonging to the RT group,
all non-root users or whatever you like.
(Just killing one would be unsafe, as one of the others might just restart the
offending process, thinking it crashed for some reason... Of course, a trojan
that really wants to kill your system would build a complex network of
SCHED_FIFO processes spawning and keeping eachother awake.)
In order to solve the root/RT user problem, this watchdog daemon could also
provide a service to set the scheduling policy for RT threads. (Available only
to the "RT users" group, probably.)
Hmm... Perhaps this is a viable solution. It requires slight modification of
RT apps to run them directly (they need to ask the watchdog daemon rather than
using sched_setscheduler() directly), but there are ways of overriding symbols
imported by binary executables. (AFAIK, esound does something of the kind to
get non-esound enabled apps to talk to the mixing daemon rather than the audio
device.)
Still, this requires users to install yet another system component in order for
some applications to run properly. If RT is to be considered anything like a
standard feature, this really belongs in the kernel, at the very least in the
form of that RT user group.
By "at the very least" I mean that 'RT users without a watchdog' and 'multi
user systems' are mutually exclusive. Maybe this doesn't sound like a big
issue, but what about public systems, like the ones at libraries and schools?
On those, you can usually download and run software, and it may not be
acceptable to trust users with RT privilege (say students using RT software)
not to use unapproved software. Not to mention programming classes where
students write their own RT code... These systems will need both some RT user
group solution and the watchdog.
So, what to do and where to put it? I'd say that it's either both RT group
support and a watchdog in the kernel, or both outside. The problem with the
first option is more kernel code, and the latter takes away the API
transparency. Apps and/or users have to know about this hack. Is that
acceptable as The way to use the Linux RT support?
//David
P r o f e s s i o n a l L i n u x A u d i o
· ··-------------------------------------------------·· ·
MuCoS - http://www.linuxdj.com/mucos
Audiality - http://www.angelfire.com/or/audiality
David Olofson - audiality_AT_swipnet.se
This archive was generated by hypermail 2b28 : Fri Mar 24 2000 - 07:20:47 EET