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
