Re: [9fans] Bits of Plan 9 I wish were more popular...

[Digby Tarvin <digbyt@acm.org>]

On Thu, Jul 03, 2008 at 08:51:22AM -0400, erik quanstrom wrote:
> > The only issue is that I can't justify the time needed to write Plan 9
> > drivers when a usable system already exists.
> >
> > > Still you could use 9vx to run plan9 on top of this system, that way you could maybe
> > > migrate the system gradually.
> >
> > Unless vx32 can run real-time tasks (pretty sure it cannot) that's not
> > much use.  Almost every bit of my code (all except a very thin command
> > interface) is living in a loadable kernel module
> >
> > Don't you want Kalman filters in *your* OS kernel?
>
> it seems suprising that it all runs in the kernel.
> doesn't linux support real-time user processes?

It all depends on how strict your interpretation of real-time is.

The situation with Linux is similar to what I recall existed in SVR4,
There is 'real-time domain' scheduling, the POSIX.4 API for finer timing
control, and you can lock processes in core to prevent them from
swapping/paging... its ok if there is a bit of buffering to smooth out
the occasional delay, such as for multimedia applications, but if
delayed response to an interrupt could cause your reactor to go
critical then it probably isn't good enough. Unix just wasn't designed
for hard real-time.

The standard solution used in LinuxRT and RTAI is essentially to run
Linux on top of a real-time kernel. Your real-time applications then
run in real-time on the same machine as your Linux apps with some
limited ability to comunicate with them, but don't have access to Linux
system calls or libraries.

Putting your time critical code into the kernel is another way to
get more predictable response times - particularly if you can do the
time critical stuff in an interrupt service routine. but again you
forgo the normal Linux/User API and library access, and you have to
be careful of drivers and other parts of the kernel which may be
masking interrupts.

It is a bit like the attempts to retrofit multi-tasking to DOS.
You are better off designing somethign that has real-time in mind
from the start and then retrofitting the Unix/Linux compatability.

Regards,
DigbyT
--
Digby R. S. Tarvin                                          digbyt(at)digbyt.com
http://www.digbyt.com