Experimental Physics and
Industrial Control System

Andrew Johnson <[email protected]> · Fri, 20 Nov 2009 14:42:35 -0600

Hi Michael,

On Monday 16 November 2009 16:52:42 Davidsaver, Michael wrote:
>
> Well Ok.  I will have to agree that the only way to achieve that level
> of granularity is at link time.  There are then only two options
> remaining.  The pointer table, or separate libraries for the osd
> functions.  The selection of a bus access library would be in the same
> manner as a readline library is selected.
>
> The only benefit offered by separate libraries is not having to deal
> with function pointers.  This is not a huge benefit, but it does make
> the code simpler and easier to follow.

There is one other difference between the two: A pointer table allows you to 
link with and talk to more than one implementation in the same IOC binary.  
Not likely to be an issue with the PCI interface, but as you've suggested it's 
at least possible that you might want to load two or more different VME 
interfaces at once.  You can't do that nicely with interchangeable libraries 
that implement the same set of routines.

> > BTW, the way I would recommend controlling the plugin would be through
> > a registrar() entry in a DBD file.  I don't have a problem with
> > requiring that IOCs using the VME interface should have to explicitly
> > include a devLibVme.dbd file say, even on vxWorks and RTEMS.  It would be
> > normally be included by the device support for the VME devices it's using
> > rather than directly by the IOC itself, but it's a valid build
> > configuration parameter and we normally specify those using DBD files.
>
> How would this work if there were two mutually exclusive options?  Say I
> have to choose between the TRIUMF library wrapper, and a hypothetical
> interface using the new Linux kernel VME API?  This sort of decision has
> to be made as late as possible.

You're right, the device support can't select which VME driver to use, that 
has to be done when building the DBD file that defines everything going into 
your IOC, so that's where the specific interface would be named.  If the API 
allows multiple simultaneous drivers then there will also have to be one or 
more initialization commands in the IOC start-up script controlling how the 
bus number selects which VME driver.  You're going to need some kind of 
command anyway for the PCI/VME bridges.

The disadvantage is that every existing VME/vxWorks IOC would probably have to 
add that initialization command; not ideal, but not totally unacceptable.  It 
might be possible to have an OS-specific default though, which would be nicer.

We should add a Bus Number field to the VME_IO link type (dbStatic/link.h) and 
have its value default to zero (dbStatic/dbStaticLib.c) if not supplied in a 
hardware link address.  That would reduce the changes needed to existing 
databases, and with Ralph's suggestion would still keep the status quo for 
existing device support while allowing conversions to the new API.

> Granted I still like the idea, but you would have to change the
> Makefiles of existing IOCs.

We allow ourselves to require that kind of change when upgrading applications 
to new versions of Base, although we do try and avoid it if we reasonably can.

- Andrew
-- 
The best FOSS code is written to be read by other humans -- Harald Welte

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System