Experimental Physics and
Industrial Control System

Andrew Johnson <[email protected]> · Tue, 10 Nov 2009 16:43:02 -0600

Hi Michael,

On Tuesday 10 November 2009 14:13:18 Davidsaver, Michael wrote:
>
> 1) No 'virtual os' table behind the devLib PCI api.

I think a virtual table would still be useful for the multiple platforms that 
devLib has to be able to support — the plug-in defines the boundary between 
the generic API and the platform-specific code.  If you don't do that, you 
either have to define a platform interface separately, or implement the devLib 
PCI code separately for each platform.

We have discovered that in practice it makes life much simpler to be able to 
compile and create libraries containing our device support code for all our 
IOC platforms, even though there is no actual devLib VME implementation 
available for Solaris or Darwin (yet).  The place where an error should be 
reported would be when trying to link an IOC executable on a platform that has 
no plug-in; I'd prefer that it not be quite as late as run-time if possible 
though.

<snip>

> 3) Add callback hooks for some specific operations.  This could be used
> for BSP specific quirks.  Before and after read/write probing would be
> one example.

Can't the BSP wrap its own probe routine if necessary?  VxWorks allow its BSPs 
to do that: vxMemProbe() vectors through the _func_vxMemProbeHook function 
pointer which the BSP usually sets.  I'm not sure this should be part of 
devLib.

> So far I have been working with the 'virtual os' table concept.  I have
> been in contact with Graham Waters of TRIUMF about their use of Linux
> with devLib.  It looks like a straight forward piece of code which wraps
> a vendor provided library for the Universe2.  It is not designed to
> insert itself at runtime.

Right, but it doesn't require any changes to Base to use it; when you compile 
Base for Linux you don't know whether you're going to be using the TRIUMF 
plugin or not.  I don't want there to be a configuration switch, because we 
need to be able to use the same build of Base to create both kinds of IOC.  If 
there's an alternative to the 'virtual os' table though I'd like to hear it 
(some vxWorks targets don't support weak symbols by the way, so they won't 
help).

> I have begun to wonder about the wisdom of maintaining the 'virtual os'
> plugin interface when there is only one plugin for it.  This is
> especially true for the PCI interface.  Both RTEMS and VxWorks have one
> uniform complete interface for PCI access, and Linux has none (for
> userspace).

I don't follow your statement that "there is only one plugin for it."  Both 
RTEMS and vxWorks provide plug-ins for the interface.  The issue that I have 
with it is that a number of routines were added to devLib that don't go 
through the function table, duplicating existing functionality in some cases.

<snip>

> However, most people will only deal with systems having a single VME
> bridge (bus #0).  The question is if it is worthwhile to change the api
> for a corner case?

I like Ralph's idea, which also gives you more flexibility to change the API 
if you need to.

- 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