EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  2006  <20072008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 2002  2003  2004  2005  2006  <20072008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: EPICS R3.14.9 and vxWorks
From: Andrew Johnson <[email protected]>
To: "Ernest L. Williams Jr." <[email protected]>
Cc: "Kasemir, Kay" <[email protected]>, "Thompson, David H." <[email protected]>, EPICS Core Talk <[email protected]>
Date: Tue, 10 Apr 2007 18:13:52 -0500
Ernest L. Williams Jr. wrote:

In the case of an ioc application, the application source code does not
change between a vxWorks 5.5.x and vxWorks 6.x kernel.

Sure; in this case the branch would only be needed to give you the two separate build trees, until you can get the vxWorks 5.5.x IOCs upgraded to vxWorks 6.x - I'm assuming that this would be one of the main points of introducing vxWorks 6 IOCs in the first place. As I said, it also gives the engineer responsible for the IOC area an incentive to upgrade his/her IOCs quickly...

However, in the case of a "share top" which contains drivers such as
vxStats there will be an impact.  So, vxStats is riddle with "ifdefs" or
a new branch is made.  In the case of vxStats we will be working on some
abstraction layer to hide vxWorks API changes.

Actually I would expect vxStats to be the one support application that really would have to be different for different versions of vxWorks, since it probably relies on the OS APIs that tend to be on the fringes of normal functionality and thus change between major versions. The advantage of starting a new IOC branch in this case is that you can link to a completely different vxStats support application for vxWorks 6, and you wouldn't need any of the ifdef stuff or an abstraction layer at all (Actually you can do that with a different target architecture too, you just have to create a configure/RELEASE.Common.vxWorks6-ppc604_long file in each IOC area to override the configure/RELEASE setting).

The compiler options are actually CPU specific and BSP specific.
One example is the altivec support, but you already handle this with an
altivec suffix in the target name.  I agree that the options may not be
necessary always.

Adding the altivec really makes it a different CPU, so it has to be a different target architecture. I'd be interested in any other examples you can find though.

- Andrew
--
The right to be heard does not automatically include
the right to be taken seriously. -- Hubert H. Humphrey

Replies:
RE: EPICS R3.14.9 and vxWorks Thompson, David H.
Re: EPICS R3.14.9 and vxWorks Ernest L. Williams Jr.
References:
EPICS R3.14.9 and vxWorks Ernest L. Williams Jr.
Re: EPICS R3.14.9 and vxWorks Andrew Johnson
Re: EPICS R3.14.9 and vxWorks Ernest L. Williams Jr.
Re: EPICS R3.14.9 and vxWorks Andrew Johnson
Re: EPICS R3.14.9 and vxWorks Ernest L. Williams Jr.

Navigate by Date:
Prev: Re: EPICS R3.14.9 and vxWorks Ernest L. Williams Jr.
Next: RE: EPICS R3.14.9 and vxWorks Thompson, David H.
Index: 2002  2003  2004  2005  2006  <20072008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: EPICS R3.14.9 and vxWorks Ernest L. Williams Jr.
Next: RE: EPICS R3.14.9 and vxWorks Thompson, David H.
Index: 2002  2003  2004  2005  2006  <20072008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Feb 2012 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·