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: "Ernest L. Williams Jr." <[email protected]>
To: Andrew Johnson <[email protected]>
Cc: "Kasemir, Kay" <[email protected]>, "Thompson, David H." <[email protected]>, EPICS Core Talk <[email protected]>
Date: Wed, 11 Apr 2007 07:09:32 -0700
On Tue, 2007-04-10 at 18:13 -0500, Andrew Johnson wrote:
> 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...
Sounds good.


> 
> > 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).
That is awesome.  I did not know you could do that with the RELEASE
file.

Thanks,
Ernest



> 
> > 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


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.
Re: EPICS R3.14.9 and vxWorks Andrew Johnson

Navigate by Date:
Prev: Re: EPICS R3.14.9 and vxWorks Ralph Lange
Next: Re: EPICS R3.14.9 and vxWorks Ernest L. Williams Jr.
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: [Fwd: Track on control system evolution] News from EPICS - proposed topics Matthias Clausen
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 ·