Experimental Physics and
Industrial Control System

[email protected] (Nick Rees) · Thu, 29 Feb 96 10:03:18 HST

Peregrine McGehee writes:

> Peregrine McGehee writes:
>  > 
>  > I've heard that several sites (including LANL) are planning on moving
>  > to Tornado - is anyone actually running EPICS with it yet?
> 
> Judging from the overwhelming silence, I'd guess the answer is 'NO!'.

The answer probably is no, but not necessarily for the reason of
silence - just the answer takes a little while to prepare.... By
coincidence, I have just a few days installing and testing Tornado and
I will endevour to relay my experiences.

The short answer is that I managed to load some databases and establish
communication with no changes to the Epics code, but I have decided to
back out of the exercise and would recommend anyone else to do so too.
Maybe Tornado 1.1 may be more appropriate for Epics, we will have to see.

The long answer is divided into two main parts. The first is more
important and concerns the limitations of Tornado itself. The second
concerns changes to the Wind River installation directories which
causes minor build headaches.

1. Limitations of Tornado.

The real problem with Tornado and the way we use VxWorks is that
Tornado uses a host resident shell and symbol table. Thus, to use the
Tornado tools properly everything has to be loaded from the host so the
host knows about the symbols.  However Epics depends on a target
resident shell (for the startup script) and target resident symbol
table (for finding the record/device/driver support entry tables).

Now, of course, (as WRS will tell you), you can have both host and
target resident shells and symbol tables, but the problem is they are
independent. So:

a. If I execute the Epics startup script on the target in the traditional
   fashion then most of the Tornado tools (debugger, shell symbol
   browser) are useless since the host symbol table only contains the
   symbols in the vxWorks image - not the Epics symbols we are
   interested in.

b. If I execute the Epics startup script by sourcing via the Tornado
   (host resident) shell a number of problems occur:

   i)   The cd commands work on the host, so loading of databases fail
	since the target hasn't changed its default directory. You can
	rectify this by doing @cd (the @ symbol idicates a target
	command), but then loading the object modules fails since the
	host hasn't changed directory. You have to do both.

   ii) If the target software attempts to look up an Epics global symbol
       it fails since these were resolved and stored on the host and
       not passed down to the target.

   Another potential problem with sourcing the startup script from the
   host (which doesn't arise because of the above), is that there is no
   way of automatically sourcing a script after a reboot.

Thus, in my opinion, if Epics is to make use of Tornado (which
currently implies a host resident symbol table) one of two things must
happen:

A. We must excise all references to the symbol table from our code,
   replace the startup script by a c routine that is called by the vxWorks
   usrRoot, and compile everything into a single image that is loaded at
   boot time.

B. WRS must create some interaction between the the host resident symbol
   table and the target resident one, such that if a target resident
   symbol table exists then it is the master copy and the host tools
   access it for the symbol information (and update it when they have
   to load more symbol information).

Currently I am guessing that this will be such a common gripe that WRS
may do the latter. I certainly will let them know about it. This is
what I mean by waiting to Tornado 1.1.

2. Changes to the installation directories.

The root of the Wind River tree now has three sub directories - host,
share and target. The meaning of these is obvious. Host systems are now
identified by a directory name containing both the architecture and the
OS - for example sun4-solaris2, rather than solaris and sun4-sunos4
rather than sun4. This opens up posibilities such as intel86-solaris2,
intel86-linux, intel86-win95, alpha_osf1, alpha_winNT etc. The existing
names have been a known deficiency for some time and so it is not clear
whether Epics should follow suit (I say probably).

All host executables are now in a single directory - on my system this
is ${WIND_BASE}/host/sun4-solaris2/bin. The GNU software has been
merged in with the rest of the tree. Other GNU tools have been added,
notably g++ and GNU make. Tcl is also used extensively on the host, but
it is compiled into the tools. gcc has been updated to 2.6, which
solves some long outstanding niggles.

Because of the adoption of GNU make the target build directories have
changed since they don't need MakeSkel anymore - the philosophy is
similar to Epics with a centralised collection of make configurations
and rules in the ${WIND_BASE}/target/h/make directory. There have also
been changes to the BSP, but old BSP's still work (but new BSP's don't
work under 5.2).

Anyway, all of this is fairly minor, but it may cause some changes to
the Epics build rules which may be difficult to make transparent.

3. Behaviour of Epics.

Well, as I said I did get Epics to compile and load under VxWorks 5.3.
And as Andy has said, Tornado is really layered on top of VxWorks, and
if you don't use any of Tornado, VxWorks 5.3 is meant to be upwards
compatible with 5.2. So I was expecting no problems and there was only
one minor one. Sometimes (but not always) I got the following after
calling iocInit:

task: 0X785ec0 tShell
Assertion failed: semStatus==OK, file ../iocLogClient.c, line 445

The relevant lines are:

       /*
        * mutex on
        */
        semStatus = semTake(iocLogMutex, WAIT_FOREVER);
	assert(semStatus==OK);

Now I feel semStatus can only not be OK if iocLogMutex is not a
semaphore. However it does work sometimes (but not always) so I suspect
a race condition that, due to a better compiler or kernel means the
semaphore is not yet initialized before it is taken, when in the past
it was.

BTW all this was done with Marty's 3.12.2.1 ascii database December
release so that may be a factor.

4. Conclusions.

I backed out of it and am now using 5.2 again. I would advise others to
do so too, but I do hope that Tornado maves in the right direction for
us since some of its tools do look useful.

I will be showing some WRS people round our site next week (they are
having an executive meeting in Hawaii or something), and will probably
make a comment to this effect. Bob, can you give me an estimate of how
many WRS licences Epics users hold so I can make the point more
effectively? My guess is we have a few hundred developer seats spread
over 40-50 site licenses. Am I right?

Nick Rees

Joint Astronomy Centre                    Ph:       +1 (808) 961-3756
660 N. Aohoku Place                       Fax:      +1 (808) 961-6516
Hilo, HI.  96720                          Internet: [email protected]

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System