[evla-sw-discuss] RTOSes ?

[Bill Sahr]

I noticed in the notes from the EVLA Coordination Meeting
of 1/28/2002, that Gareth is on record as finding the notion
of using more than one rtos "unacceptable".

I am wondering what the opinion of other members of this
discussion group might be on this matter.

I see three contexts in which an rtos might be used - 
1) the MIBs for the antenna hardware and ancillary
devices (such as the API), 2) the MIBs on the correlator 
boards, and 3) the real-time crates that will run the 
applications which perform tasks such as geometry 
calculations, checker functions, data-flagging, higher 
level, overall correlator monitor and control and 
communication with the correlator backed, etc, etc.

Frankly, my own position on the matter is that we might
end up with more than one rtos, and that we it would not
be a disaster if such were the case.  Would I prefer
one rtos ?  Yes.  However, we have a great deal of
real-time experience within the group.  Nearly all of
us have worked with several different rtoses over the
course of our careers.  All of them must do pretty much
the same sort of thing, and most of them can be learned 
rather quickly.  In my experience, when working with 
a small, modular, lean rtos one can begin to do useful 
work in a little as 4 weeks.

The same rtos may simply not be the right tool for all
three contexts.  For the antenna MIB we want an rtos
that is as compact as possible, offers a minimum of
real-time functionality and incorporates a TCP/IP
protocol stack.  The correlator MIB presents a situation
that is considerably less limited with respect to resources,
and may benefit from a more varied and extensive set
of capabiliites.  The real-time crates are yet another
class of applications.

My deepest reservation concerns the use of real-time linuxes 
of one sort or another.  Not only is the programming style 
quite different from the approach taken for non-Linux work, 
but also, I feel that Linux has technical characteristics 
which make it fundamentally inappropriate for real-time work.  
The  patches and modifications made to Linux to adapt it to
real-time strike me a kludges which tend to mire one
in systems level rather than applications level 
considerations.  (If real-time Linux were appropriate
to any component of the system, I would use it for
item 3 as listed above - the real-time crates and not
in an embedded context.

However, this note is not meant to be a rant against real-
time Linux, but rather an attempt to get feedback from the
discussion group members on your feelings concerning the
importance of trying to use one rtos for all components
of the system.  I would be very interested in hearing your
opinions on this matter - both from those primarily
involved in the hardware, and from those primarily considering
the software.

Bill