VxWorks vs. RTEMS

[gregory.menke at gsfc.nasa.gov]

Gene Smith writes:
 > I know rtems has a posix compatibility layer that can be used. Has 
 > anyone ever thought about making a similar layer that would map vxWorks 
 > calls to rtems calls? Or is this even possible in a meaningful way? A 
 > formal comparison between rtems and vxworks is in a paper by Till Straumann
 > 
 > http://epaper.kek.jp/ica01/papers/WEBI001.pdf

 > that concludes that their performance is about the same and states that 
 > they both don't provide memory protection for tasks nor virtual
 > memory. 
 
I've done some benchmarking on that topic as well and drew similar
conclusions- the performance of the 2 os's in terms of OS overhead per
system call, and across context switches was too close to plausibly
differentiate between them.

 > Is that still true? (I have seen mention of a virtual memory library for 
 > vx called vxmem.)

There have been a few vxWorks compatability libraries written to
emulate various bits of the api, but matching vxWorks feature for
feature and bug for bug is a lot of work.  In general you're better
served by implementing some kind of abstraction layer to centralize
the OS-specific stuff and make it easier to port.  The posix api is
nice for portability and generic functionality, but it kind of sucks
when you start wanting specific behavior.


 > I have an application that uses vxWorks and am considering porting it to 
 > rtems. I am not sure if this ppc based vxworks application uses memory 
 > protect or not. Pretty sure it does not use virtual memory.
 > 
 > Comment/question appreciated.

On the ppc, RTEMS sets up page tables to trap bogus pointers, but no
virtual memory.  Thats probably about the same as vxWorks.  OTOH, the
PPC pagetable stuff in RTEMS is quite involved, my sense is its nearly
to the point where backing store could be put in place to provide some
form of vm.

Does your application really need vm, or is it mostly looking for
process protection?  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.  LynxOS is a
great example of a realtime, process oriented, virtual memory OS- its
a nice product, but the cpu-time overhead is roughly twice that of
RTEMS & vxWorks.

Gregm