Experimental Physics and
Industrial Control System

"Thompson, David H." <[email protected]> · Wed, 11 Apr 2007 07:56:24 -0400

Always been my preference to embed the abstraction layer needed for DMA, vxStats and whatever in the BSP.  In reality it is hard to get in front of all this on a construction schedule, even tho it would be eaiser for all in the long run.  Bunches of ifdefs in module code are a sign that a wrong choice is being payed for over time.  There is also a school of thought that kernels should be only modified in ways that are supported by the WRS config tools, and that modifications to sources in the BSP should not be done. An alternative is to load a kernel specific epics support module post-boot and before any epics modules are loaded. That may be the best of all worlds, and we could share those between the labs.

We simulated an epics $SHARE modue that includes the loadable boot file, that could be spcified in the RELEASE file which would follow the proceedure as Andrew suggests, but then we chose to include the RULES_BUILD from the vxWorks module in the iocBoof/iocxxx/Makefile instead.  
A rule in the BSP's RULES_BUILD installs the symbolic links in the ioc's common boot directory for the kernel for booting.  It also make our versioning and roll back pretty easy.

I think Andrew's model for upgrading fits the configuration control discipline a lot better, you have separate releases anyway when you either change the epics release or the kernel release.

________________________________

From: Andrew Johnson [mailto:[email protected]]
Sent: Tue 4/10/2007 7:13 PM
To: Williams Jr, Ernest L.
Cc: Kasemir, Kay; Thompson, David H.; EPICS Core Talk
Subject: Re: EPICS R3.14.9 and vxWorks

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

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System