Experimental Physics and
Industrial Control System

"Davidsaver, Michael" <[email protected]> · Fri, 13 Nov 2009 18:15:53 -0500

This patch set puts all the existing public devLib functions under the function pointer table.  It will break outside users of the plugin, but the fix is not difficult.  The only thing it doesn't addressed is the global epicsAddressTypeName variable, but fixing that would mean a change to the public API.

I have tested this on RTEMS, but not vxWorks.

0001 and 0002 - There are already table entries for (dis)connect VME interrupts.  Use them.

0003 - Add VME interrupt in use to the table.

0004 - Mark all OSD functions as static

0005 - Move table definition to a separate file

0006 - Reorganize devLib.h to group functions by bus type

0007 - use sharelib.h extern macro for public variables

-----Original Message-----
From: [email protected] on behalf of Davidsaver, Michael
Sent: Fri 11/13/2009 8:40 AM
To: Andrew Johnson; [email protected]
Subject: RE: devLib ruminations

Hi Andrew,

Thanks for the comments.

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

Instead of function pointers I would just use the usual osi+osd function pairs.  User calls osiFoo() which does some common operations, then osiFoo() calls osdFoo() which is specialized for the target.

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

In an expanded devLib PCI code needs to be able to work for targets which have no VME support, and vice versa.

While I would agree that run-time is too late, I think that link-time is also too late.  Missing symbols are not a very friendly way to find out.  Compile time is better since more informative error messages can be given with the #error directive.

I would make 2 changes.  First, osi/os/default/devLib*.c would contain a stub implementation to give something to link against.  Second, create a header called osi/os/*/devLibConfig.h which would #define HAVE_DEVLIBVME and HAVE_DEVLIBPCI.  Trying to include 'devLibPCI.h' when HAVE_DEVLIBPCI is not defined would be an #error.

Call this the 'autoconf' approach.

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

Fine.  I just wanted to put this out as a possibility.

> > 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 think what you mean is that you don't want a single global configuration switch.  You are correct that this wouldn't work.

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

Yes, they each provide _A_ plugin.  There is _A_ plugin for Linux.  The plugin functionality is not being used.

I agree that if we use the pointer table it should be all or nothing.  I have a patch set from the code-a-thon which corrects the current situation, which I will post later today.

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

The question was: Should devLibVME handle multiple VME bridges?  This sounds like a yes.

If so then the above only applies to the purposed new PCI part of devLib.  The VME part would still use a pointer table, or rather tables.

Michael

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System