BTW, some random notes on doing `real-time' support:

* Other timing constraints aside, Curt's `limit CPU to 80%' isn't
  conceptually different from a deadman switch, and could be
  implemented in the same fashion (i.e. one-shot fires and forces a
  context switch).  Of course it has to be documented and
  configurable, but that's a different issue.

* With I/O threads, it should actually be possible to disable hardware
  interrupts for devices whose I/O threads are at a lower priority
  than the currently running task.  I haven't implemented this, and I
  don't have any plans to, but someone else could.

* You'd still want to prevent clock interrupts from causing jitter.
  Probably the simplest thing to do is either get rid of the absolute
  time reference or put it in hardware.  If you have a fixed maximum
  scheduling interval (as mentioned above), you could also use a
  smaller free-running counter and check it for rollover on each
  switch, as well as scheduling the timeout for the next task switch.
  (NextStep does something like this.)

* You still have to get rid of other jitter sources -- including the
  MMU/TLB and caches.  The big one here is the MMU.  It's not enough
  to just mlock() everything, because you're still using the TLB,
  which introduces an element of randomness.  The solution to this is
  really the same as for `embedded' MMU-less systems: link everything
  as PIC code, so it can be loaded anywhere, get rid of all other
  fixed memory addresses (primarily the location of the stack), and
  run everything in a single address space.

It'd actually be nifty if someone worked on this -- particularly the
last part -- mainly because it would enable NetBSD to run on small
embedded systems like printers and Pilots.