Experimental Physics and
Industrial Control System

"Davidsaver, Michael" <[email protected]> · Mon, 23 Nov 2009 16:51:30 -0500

Andrew,

> -----Original Message-----
> From: Andrew Johnson [mailto:[email protected]]
> Sent: Friday, November 20, 2009 3:43 PM
> To: Davidsaver, Michael
> Cc: [email protected]
> Subject: Re: devLib ruminations
> 
> 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.

Ok, pointer table it is.

> > > 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.

Only RTEMS and vxWorks would need defaults.

> 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.

If I were changing VME_IO I would make it something like.

'#B0 A32 C0x420000 S0 @'

B - bus number (0 if omitted)
A - Address modifier (16, 24, 32, or CSR)
C - base address (epicsUInt32, not short)
S - extra parameter for whatever (also 32 bit)

But it is probably not worth it since most new code uses an iocsh
function to set the address info anyway.

> > 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