According to Erik E. Fair:
>
>Perhaps it's time to go through the myriad numbers of papers given at
>USENIX over the years on the topic of Real Time Scheduling (and maybe the
>IEEE 1003.12 stuff? Those guys were just outta control) and consider adding
>a mechanism for real time response to NetBSD's scheduler.
>

I was talking to a friend of mine that has been tracking/using the RT
version of Linux.  From what he was saying the way that linux did it
was to, effectively, run a process in an interrupt context - this way
there are no scheduler hacks to do and linux gets run when there are
no RT processes to run.  I would imagine that the RT process in this
sort of setup would be _very_ limited in what it could do - updating
hardware regs or memory behind the kernel's back could be rather
fatal.  As for doing a cd-r this way, I _think_ that it could be made
to work by putting a bit of buffer memory somewhere that the unix
process adds to the tail and the RT process updates the head - have
the cd-r on a separate scsi controller so you can intercept the
interrupts and start the RT process - dunno if you have to resort to
bloating the RT process with an entire scsi driver or if there is some
sane way to share the kernel ones (I suspect the former would be the
simplest but not very elegant way it would have to be done).

-- 
Brett Lymn, Computer Systems Administrator, AWA Defence Industries
===============================================================================
  "Upgrading your memory gives you MORE RAM!" - ad in MacWAREHOUSE catalogue.