Hello!

I have been working on a vxWorks clone for since
this spring. It will take a while to complete
i suspect since it's a free time work.

Currently on focusing on the x86 plattform, since
I'm developing on a Linux pc.
It has been attempts to port it to sh4 on Dreamcast,
but that has been put on hold for now.

I would appreciate if you would like to help me:
(don't be misled by the "virual memory" in the name,
that was just added when mmu support was included).
PS. If you would like to look at the code, please
download from the CVS tree. The file download
contains an old buggy scheduler...

Please check it out:
http://sourceforge.net/projects/vmx/

Homepage with instructions how to compiler and install:
http://vmx.sourceforge.net/

If you would like to contribute, register
on sourceforge and I will add you with
developer access.

On Tuesday 16 September 2008 10:36:13 orocos [..] ... wrote:
> Dear Orocos Developers,
> I see you did a poll some time ago to find out what ports people might like
> and VxWorks got zero votes. This surprises me, but maybe its because it is
> expensive and proprietary. I guess most Orocos users are looking for
> open-source solutions. Anyway, I just wonder how difficult or time
> consuming you think it would be to port to VxWorks. I'm not asking for it
> to be done, but I would like to gauge the effort you feel would be required
> (I would imagine it could be ported quite readily myself). Thanks,

From our experiences with the MacOSX port, the hardest part is modifying the
build system, and not porting the OS-layer. In case of VxWorks, that would
mean checking if cross-compilation is fully supported (it should, but it is
untested for CORBA for example.) You'll require CMake 2.6 at least and this
information:

I know of a company that ported Orocos to their own OS, created their own
cross-compilation makefiles and wrote their own rtt-config.h file (they were
not using CORBA). Although such efforts will not be merged with trunk, it is
also an option.

For porting the RTT sources, you'll have working code in a matter of days,
given that you're using GCC and one of i386, amd86 or powerpc. This excludes
required days for tweaking the build system.

For porting the OCL sources, it will depend on your platform. You need to get
readline for the taskbrowser[*] and dlopen() for the deployer. Hardware
device drivers are another category we couldn't estimate right now.

Peter

[*] The taskbrowser can be compiled without readline by using the -DNO_GPL
compiler flag. It will use native C++ iostreams then.