[comp.realtime] VxWorks and SysV ?

devil@techunix.BITNET (Gil Tene) (07/16/90)

I have read some VxWorks tech info sheets, and this system seems
to be every unix programmer's dream for a Real Time OS + development
environment... I noticed one think lacking though : VxWorks is
"BSD 4.3 compatible" in system calls, but it says nothing about SysV.

Does this mean that all those nice SysV IPC things (Shared memory,
message queues, semaphores) won't work with VxWorks ? Are there
any GOOD replacement tools that DO come with VxWorks ? I find that
semaphores and/or message queues are very much needed, and that
shared memory is a MUST in my application development...

AdvThanks,

Gil.
--
--------------------------------------------------------------------
| Gil Tene                      "Some days it just doesn't pay     |
| devil@techunix.technion.ac.il   to go to sleep in the morning."  |
--------------------------------------------------------------------

u096000@lanl.gov (Roger A. Cole) (07/17/90)

I have some input on the issue of VxWorks compatibility.  To put my
comments in perspective, you should know that I have only 1 year
experience with UNIX (SunOS) and VxWorks.

What I have found is that VxWorks and SunOS are, at best, compatible
only superficially.  Incompatibilities start with names of header files
and escalate.  VxWorks pipes aren't the same as SunOS pipes; VxWorks
select() works only on sockets; VxWorks task and semaphore routines don't
have direct counterparts under SunOS; the VxWorks "C library" has differences
from the SunOS C library; etc.

My goal with my work has been to compose a program which will compile for
either SunOS or VxWorks, and which will operate "the same" under both.  I
have partially achieved this goal with some "compatibility code" which
mimics (under SunOS, using lightweight processes and the non-blocking
i/o library) the VxWorks features I need.

The bottom line for me is: 1) I can have source level compatibility with
some restrictions and with some decrease in my productivity; 2) there is
losts of room for improvement in VxWorks; and 3) many VxWorks claims to
compatibility are dangerously misleading.

I get my work done with VxWorks, and I don't have any real regrets about
using VxWorks, but it definitely isn't a bed of roses.

Roger Cole, Los Alamos National Laboratory,  internet: cole@luke.LANL.GOV

zhang@cs.rochester.edu (Zhang Ju) (07/18/90)

Anybody can kindly e-mail me the name of the vendor for VxWorks?

I also want to see discussions about the experience of using pSOS+ and
VRTX. The place I am working is considering choosing a realtime system.

				Ju Zhang