Experimental Physics and
Industrial Control System

Andrew Johnson <[email protected]> · Wed, 20 Apr 2016 15:35:14 -0500

Hi Mike,

On 04/20/2016 12:31 PM, Michael Westfall wrote:
> We are in fact wanting to port the vmi5588 driver to EPICS OSI
> compliance, so that it can run on an RTEMS IOC.
> 
> Since you wrote that driver originally, maybe you have some idea as to
> how to proceed?

Wow, I haven't looked at that code since the '90s. Do you know of any
changes made since the 2002 version published by Observatory Sciences?
BTW OSL only seem to be publishing the driver code, so I don't have
access to the device support at all. Looking at the source code that I
just downloaded from them I can see why you are asking about the
registry, but unfortunately I don't think it quite fits what you need to
replace symLib.

Neither the registry nor the underlying gpHash facility from libCom
provide an suitable equivalent to the symEach() function that is called
in rmPrintSymbols() to scan through all of the known symbols in turn.
That means you'll have to write a bit more code in the driver to fully
replace symLib, and I would recommend using libCom's gpHash facility
directly to avoid the registry's overhead.

In order to be able to scan all of the loaded symbols the driver will
have to keep a linked list of them, and it will also need a gpHash to do
fast lookups by name. There are several examples found in Base's
dbStatic library, look at how drivers (struct drvSup) are stored (by
dbDriver() in dbLexRoutines.c) and retrieved (sequentially from the
pdbbase->drvList by dbWriteDriverFP() and by name lookup in the
pdbbase->pgpHash by dbFindDriver() in dbStaticLib.c).

You should create your own gpHash table using gphInitPvt() rather than
trying to re-use the one in pdbbase, and you'll also need an ELLLIST.
For each symbol you'll need a data structure like the struct drvSup
containing an ELLNODE, a name, and storage for the page number and
offset (or you could combine them into a single epicsInt32).

Note that the 3rd argument to the gphFind() and gphAdd() routines can be
any pointer; its value is only used to distinguish between different
types of objects stored in the hash table — the same pointer value must
be passed to gphFind() that was given in gphAdd() for the object being
looked for. It doesn't matter what it actually points to though, and in
this case I would use a different pointer for each of the RM_TYPE_*
symbol types.

HTH; if you need more detail on anything let me know. I'd also be happy
to review your code changes if you like.

- Andrew

-- 
There are only two hard problems in distributed systems:
  2. Exactly-once delivery
  1. Guaranteed order of messages
  2. Exactly-once delivery
 -- Mathias Verraes

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System