[Xenomai-main] Re: Xenomai questions

[Philippe Gerum]

Hello,

Peter Nau wrote:

 >      (An important background note: our application is a medical one, and
 > it is subject to U.S. FDA scrutiny and regulations.  Conservative elements
 > here are skeptical about open source, free software, but the point is that
 > software quality control is essential, which we must often do ourselves.)
 > 

I know what you mean about "elements being conservative". As you can
imagine, I have no particular solution to this problem, except perhaps
contributing code and sharing ideas until the not so obvious becomes
eligible in those people minds. A recursive solution to a recurring
problem :o)

 > My questions:
 > *    Is my vision a reasonable one?  

I think it is. It's exactely what I envisioned Xenomai to be useful
for (http://www.nongnu.org/xenomai/perspective.html).

 > *    Can the VxWorks code communicate with RTAI and Linux, and vice
 > versa?  If so, what is the mechanism?

Xenomai real-time threads are running in the Linux kernel space, so
they can share memory with any Linux driver. There is also a Xenomai
driver called DBridge (like Domain Bridge) which allows Xenomai
real-time threads to exchange data back and forth with regular Linux
processes through a special device file (mostly like RTAI's fifo).
Running Xenomai threads along with RTAI tasks on their respective
scheduler will require to share the timer tick between both, but it's
feasible.

 > *    How robust and reliable is Xenomai and its VxWorks emulation, at
 > least for plain vanilla operations?

It is robust enough to run the testsuite shipped with the VxWorks
emulator. I will distinguish two layers here: the nanokernel which
happily runs a set of emulators, and the emulator itself. The
nanokernel might be more mature since it is older and has been used in
more contexts. The VxWorks emulator successfully passes its testsuite,
which means that all the emulated services it provides seem to work as
explained in the VxWorks API documentation (and according to the
knowledge of the developers about VxWorks).

I can only say that all the Xenomai development has been made using a
dual approach including event-driven simulation and real-world test
harnessing. Using the virtual machine helped removing critical
synchronization problems in a way that cannot be achieved using actual
hardware. Of course there is no such software like bug-free software,
but IMHO and above this, an important point is "to what extent can I
trust my testing of the software?". In this respect, I would say that
having the ability to run all the software stack from the nanokernel
to the application on behalf of an event-driven simulator before
putting it on the final hw platform is a good move in the right
direction. Not to mention that the Xenomai kernel and emulator code is
available for all eyes to look at it too.

 > *    Are other people using Xenomai, and is there an active or
 > semi-active user community which might help answer questions and provide
 > support, until we can do the same?
 >

Sadly enough, a simple look to the list archive will show you that
there is almost no active community aside of the developers
themselves. There are currently three people working at different
paces on this project, including myself. This is the reason why we try
to document as many things as we can so less information is lost over
time, including the nanokernel API that we use to build the emulators
(http://www.nongnu.org/xenomai/doc/api/).

Since Xenomai's user base is probably thin, I guess you will have few
answers to your questions from a scarce community, except the
developer ones.

To finish on a positive note, I'll say that most of my time has been
dedicated to contributing to the next RTAI (24.1.11) release during
the last 3 months (i.e. porting RTAI over the Adeos nanokernel)
because I see RTAI, Adeos and Xenomai as converging contributions
toward a practical free software solution in the RTOS field. The other
more serious reason is because it's fun :o)

Best regards,
 
Philippe.