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
<2007>
2008
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
<2007>
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|