Experimental Physics and
Industrial Control System

"Davidsaver, Michael" <[email protected]> · Fri, 13 Nov 2009 08:40:50 -0500

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