Experimental Physics and Industrial Control System
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
<2009>
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- 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
<2009>
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024