| 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 2025 | 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 2025 |
| <== Date ==> | <== Thread ==> |
|---|
| Subject: | Re: Vme support in devLib for Linux |
| From: | Michael Davidsaver <[email protected]> |
| To: | [email protected] |
| Date: | Tue, 18 Feb 2014 11:22:02 -0500 |
On 02/17/2014 11:43 AM, Andrew Johnson wrote:
Hi Jane, On 02/14/2014 05:55 PM, Jane Richards wrote:... However release 3.14.12 introduced a "devLib cleanup" which changed the API and broke our code. We now want to update our code to a sustainable model. How should we proceed?
This cleanup was my doing. The main goal was to fix some inconsistencies in the API (not all functions used the jump table). This allows the null implementation to actually link for targets other than RTEMS/vxWorks.
It also makes it possible to compile in multiple implementations and choose one at runtime. This was handy once when lack of hardware access forced me to develop against a simulated device.
Hopefully the changes we made should not require too much in the way of modifications to your implementation.
If you're only replicating the vxWorks API (and simply copying the vxWorks version of devLibVMEOSD.c to src/libCom/osi/os/Linux/) then I'm surprised you have problems. The usage of the vxWorks API hasn't changed.
I'm happy to help you work through these problems. It might be best to take this process off the mailing list.
Michael