Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014  2015  2016  2017  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014  2015  2016  2017 
<== Date ==> <== Thread ==>

Subject: devLib changes
From: "Davidsaver, Michael" <mdavidsaver@bnl.gov>
To: "EPICS tech-talk" <tech-talk@aps.anl.gov>
Date: Thu, 22 Oct 2009 06:26:43 -0400
All,

I have in mind some changes to devLib which I would like to discuss.  I am posting this to Tech-Talk to try to get an idea of how much interest there is in this.

I am especially interested in hearing from anyone who has had reason to use or change 'pdevLibVirtualOS'.

As it exists now devLib is quite minimal and VME heavy.  I would like to expand it to include PCI as a first class citizen, and also to make future changes less painful.  However, doing this correctly will mean making significant changes now.

Initially I would target the RTEMS and vxWorks implementations in Base, but I would be happy to add to this list.

1) split devLib

Have separate headers (devLibVME.h and devLibPCI.h) and virtual os pointer tables for each bus.  The places where there is overlap (ie devRegisterAddress or devReadProbe) would either be in a shared header (devLibCom.h) or duplicated (and specialized) for each bus type.

The devLib.h header would be reserved for the compatibility API.

2) Support PCI

Mostly this will mean adding an interface to search for devices, and access to PCI config space.  The function of searching would be to match on the various identifiers, like (sub)vendor and (sub)device ids, and return the bus-device-function triplets for each.  There would also be some convenience functions to directly fetch base addresses.

3) Uniform endian-aware hardware access library.

This would include things like register access macros (ie LE_READ16(addr)) and memory barriers.  The constructs needed are fairly well defined, so putting a wrapper around the various OS differences will be the problem here.

As it stands now this is done either using OS dependent, or homegrown calls.  On most architectures a correct implementation will be more then just using volatile pointers.  These defeat compiler reordering, but for example may not defeat CPU instruction reordering at runtime.

4) Backwards Compatibility

Because it is so minimal, I think we can preserves compatibility with most of the existing devLib API.  The exception will be the virtual os table (pdevLibVirtualOS).  Most applications don't interact with this directly, but (I am told) there are a few important ones which do.  These would need special handling.

Or, we could just ignore the existing devLib implementation, and the names it uses, and duplicate everything.  I would rather not do this, but it is an option which guarantees 100% backwards compatibility.


Thoughts?

Michael Davidsaver
NSLSII Controls Group
Brookhaven National Lab



References:
compiling streamDevice with CALC set fails Dr. Peter Zumbruch
Re: compiling streamDevice with CALC set fails Tim Mooney
Re: compiling streamDevice with CALC set fails Dr. Peter Zumbruch

Navigate by Date:
Prev: Re: compiling streamDevice with CALC set fails Dr. Peter Zumbruch
Next: Please don't reply when not replying Benjamin Franksen
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014  2015  2016  2017 
Navigate by Thread:
Prev: Re: compiling streamDevice with CALC set fails Dr. Peter Zumbruch
Next: Re: compiling streamDevice with CALC set fails Dirk Zimoch
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014  2015  2016  2017 
ANJ, 31 Jan 2014 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·