Experimental Physics and
Industrial Control System

"Davidsaver, Michael" <[email protected]> · Mon, 16 Nov 2009 17:52:42 -0500

Andrew,

> [...]
> 
> I agree that generating errors at compile-time is more friendly, but I
> don't
> know how to ask a compiler to predict the future.  I don't believe the
> compiler can ever solve my main issue: I don't want to have two
> different
> installations of Base whose only difference is whether HAVE_DEVLIBVME
> is
> defined for any particular target/OS, and nor do I want to have two
> targets
> that differ only by that setting.
> 
> Currently none of the APS Accelerator IOCs use the PCI to VME
> interface, so we
> would have no reason to define HAVE_DEVLIBVME in our build of Base for
> the
> linux-x86 target.  However if one of our customers asks us to create a
> system
> where it makes sense to use that board on a linux-x86 box, I want our
> applications engineers to be able to download the relevant driver
> module,
> build it, and link the result into a new IOC image that is built
> against our
> standard installation of Base.  Link time is the earliest moment when
> we have
> all of the information about what a specific IOC's configuration is
> going to
> be, so the only way I can see to get the flexibility I need is for the
> linker
> to be the tool that discovers whether the requested configuration is
> valid or
> not.  If you have an alternative that will meet the above requirements
> though
> I'll be happy to hear about it.

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.

> [...]
> 
> > > I like Ralph's idea, which also gives you more flexibility to
> change the
> > > API if you need to.
> >
> > The question was: Should devLibVME handle multiple VME bridges?
This
> > sounds like a yes.
> 
> I have to admit I don't see it being used very much, so I'm probably
on
> the
> fence about whether to include the capability or not.  I guess the
> problem
> with Ralph's idea is that it wouldn't be possible to use an old-style
> driver
> for any VME board that is found on the secondary bus, so maybe it
> doesn't
> really help that much in practice and the answer should be no?

The only example I can find is at the CLS where they have/had four SIS
PCI to VME bridges in one PC.  However, consider the work needed to
change the drivers for every VME card to be used.

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

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

Michael

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System