VxWorks vs. RTEMS

[Joel Sherrill <joel@OARcorp.com>]

Jack Cawkwell wrote:
> gregory.menke at gsfc.nasa.gov on Monday, August 9, 2004 at 4:22 AM  wrote:
> 
> ...
> 
>>>One of the reasons that vxWorks and RTEMS are so
>>>much faster than conventional operating systems is 
>>>they don't have to spend time fooling around with vm
>>>hardware whenever a context switch occurs- thats the
>>>tradeoff you make; speed vs protection. 
> 
> ...
> 
> Slightly off the topic: is this important in life 
> critical applications? Would authorities approving 
> critical systems be happier, or even insist on, using 
> hardware context switching, for reasons of safety?

Just to make sure it isn't getting confused in the
discussion, there is no special hardware assistance
for the context switch.  For a non-VM OS like RTEMS,
we switch the registers that are potentially
modified by the application under the standard
calling convention for the CPU.  When you add
thread/process specific memory protection with or
without backing store, you just end up having to
switch more context.  Now the MMU is part of the
context.  So it is just more complex.

I would guess that adding VM and backing store would
make the safety folks cringe if they considered the
impact of code not being in memory upon latency.
Plus if the backing store were a hard drive, that would
introduce a moving part which could fail.

VM/protection does give you some protection.
The question I always have is "and if a process does
die, what are you going to do?"  Unless you
plan for processes to die and have a mechanism in place
to recover and continue, it is still a failure.  I have
written LynxOS applications before and yes we did get
core dumps sometimes that were useful for debugging
but the application itself didn't know how to recover
from a failed process.  On the downside, when it came
time to debug some application problem which required
knowledge of what LynxOS was doing under the hood, I
felt like a blind man with no source.

With RTEMS, you can get some degree of protection by
making the text area non-writeable or executable only.
You can also use the stack allocation extensions to
make each task stack its own special area of mepped
memory with illegal addresses at each end.  This way
there will be a fault it over or underflows.

--joel