Re: What VxWorks version to officially support?

[Dirk Z. <dir...@ps...>]

On 19.02.2013 10:25, White, Greg wrote:
> Hi, thanks Andrew. Let's add this to the Wednesday meeting agenda.
>
> One comment here, and a couple more inline.
>
>> From experience, each additional support configuration (eg vxWorks<  6)
> increases effort non-linearly (though maybe only ^1.5). Still, a lot, and
> you have to be careful to avoid the situation in which functionality effort is
> swamped by support effort.
>
> *Dirk* can you remind us of PSI's requirement with respect to vxWorks?

We use vxWorks 5.5. With earlier versions it is hopeless to try to use 
boost.

Why not "simply" upgrade from vxWorks 5 to 6? Because it is not simple. 
First there are license issues. This makes upgrading expensive. Then 
vxWorks 6 uses a completely different environment system (based on 
eclipse instead of the Tornado tools). Thus there are significant 
learning costs (if you ever used Tornado and not only the command line 
compiler). But most important: vxWorks 6 is not compatible to vxWorks 5. 
The shell works differently. The network stack is new. BSPs do not look 
the same. If you use 3rd party code (e.g. for certain hardware drivers) 
and don't have the source code, you cannot use the library in a 
different vxWorks version.

> you have to be careful to avoid the situation in which functionality effort is
> swamped by support effort.

Without vxWorks 5.5 support, functionality is zero for me. Thus I would 
not see a reason to spent ANY effort on EPICS 4 any more.

>
> *Dirk*, *Timo*, what V4 functionality would cause PSI to invest in a Windows port?

We have windows IOC, mainly for cameras at the moment, because the 
drivers are only available as Windows DLLs. But especially for images is 
looks interesting to use NTImage instead of a collection of waveform and 
other records. In order to provide data consistency, the NTImage must be 
constructed on the same computer where the image and its meta-data are. 
Thus we need EPICS 4 on windows.


irk



>
> Cheers
> Greg
>
> On Feb 18, 2013, at 8:14 PM, Andrew Johnson<an...@ap...>  wrote:
>
>> Hi Matej,
>>
>> As far as APS is concerned I'd be OK with v4 only supporting vxWorks 6.x, but
>> many other sites (e.g. BESSY where Ralph works, and maybe Diamond but I'm not
>> sure about that) only have access to vxWorks 5.5 because the major upgrade to
>> 6 is really expensive.  Dirk had other reasons for wanting to continue to use
>> vxWorks 5.5 but I forget what they were; he might have mentioned them in an
>> email in the archive.  Anyhow, that's why I'm trying to keep 3.15 running on
>> vxWorks 5.5 if possible.
>
>> I would want to have an open discussion on tech-talk
>> to find out who would be adversely affected if we do have to drop 5.5.
>
> "Show us the money." I agree, but we reserve the right to make support
> effort based on participation in the working group and on real use of V4.
>
>>
>> Any lab that has a vxWorks 6.x license should be able to upgrade as they're
>> almost certainly paying annual license fees for it, so if we do decide that we
>> can't support the 5.5 compiler then I think v4 could reasonably say that it
>> requires at least vxWorks 6.6 for gcc 4.1.2 (assuming there are significant
>> reasons for wanting gcc 4.x).
>>
>> We also have to support the Microsoft Visual C++ compiler on Windows though,
>> which has its own foibles, and the MinGW compiler which combines the gcc 4.x
>> compiler with the Windows APIs.  I don't know if anyone has tried building
>> pvData and pvAccess on win32-x86 or windows-x64 yet, but my guess is that it
>> won't build because there are no epicsShare* decorations in the code.  Note
>> that it is possible to debug these on other OSs using gcc's -fvisibility
>> options.
>
> Sure, but again let's be clear about cost benefit to the labs presently
> participating in V4. So, rather than blindly support MS if we ourselves don't
> have a need for MS, I would rather we have a clear statement of what archs are
> and are not supported, plus a statement to the effect that developers for archs
> which are not in the supported list, are invited to ask for help to make a port.
>
> Having said that, PSI I think may be persuaded to do the MS port. *Timo*?
>
>>
>> I haven't got to installing and trying Boost with vxWorks yet — I have Jenkins
>> running on a test machine here and got it to build Base 3.15 for vxWorks 5.5.2
>> last week, but I may have to have it installed officially on a server to set
>> up a vxWorks 6.x build (the jenkins user account it runs as needs to be a
>> member of a specific Unix group to get access to the vxWorks compiler and
>> header files).
>>
>> I would of course prefer that we not require Boost, but I don't want to make
>> your life too difficult.  If/when we merge the v4 code into Base we can set up
>> the build so that if the user doesn't provide a link to Boost it just won't
>> build the V4 stuff, so sites can still just use the v3 IOC alone.
>
> Can a guru remind me for what we use boost (is it only for reference counted memory
> management?). What are the implications for having no dependency on Boost?
>
>>
>> One suggestion: Could you at least create a wrapper with an EPICS- or pv-named
>> API, and change all the code to use that API instead of the raw Boost one?
>> Then if someone re-implements the necessary functionality locally we won't
>> have to go through and change all the places where it's used at that time, by
>> when its usage will probably have spread too widely to be able to actually
>> remove the need for Boost.
>>
>> HTH,
>>
>> - Andrew
>>
>> On 2013-02-18 you wrote:
>>> Another thing... what do you think about EPICSv4 dependency on boost?
>>> Sure, it's a PITA to have additional/external dependency.
>>>
>>> Matej
>>>
>>> On Mon, Feb 18, 2013 at 11:10 AM, Matej Sekoranja
>>>
>>> <mat...@co...>  wrote:
>>>> Hi, Andrew!
>>>>
>>>> I am writing a document on what platforms/compilers EPICSv4 modules
>>>> officially support.
>>>> Year(s) ago you've written the following paragraph:
>>>>
>>>> "
>>>> Even vxWorks 5.4 didn't have a C++ compiler that old, although their C
>>>> compiler was — they used a Cygnus C++ front end called 2.96+.  I don't
>>>> think we should be targeting vxWorks<  6.x (minimum gcc 3.3.2) for new
>>>> developments like this, and we could probably even require>= 6.6 which
>>>> introduced gcc 4.1.2 if we wanted to.
>>>> base/configure/os/CONFIG.Common.vxWorksCommon has a list of gcc versions,
>>>> look above the definition of VX_GNU_VERSION. "
>>>>
>>>> I am now deciding wether to support VxWorks from 6.x or 6.6 on.
>>>> It's basically gcc 3.3.2 vs 4.12.
>>>> Having gcc v4 is good, however is there much of 6.0 - 6.5 installations
>>>> that will be interested in EPICSv4 in next years?
>>>>
>>>> Cheers,
>>>> Matej
>>
>> --
>> There is no such thing as a free lunch.  When invited for lunch,
>> it is best to check if you are there to eat, or to be eaten.
>> -- Clive Robinson
>>
>> ------------------------------------------------------------------------------
>> The Go Parallel Website, sponsored by Intel - in partnership with Geeknet,
>> is your hub for all things parallel software development, from weekly thought
>> leadership blogs to news, videos, case studies, tutorials, tech docs,
>> whitepapers, evaluation guides, and opinion stories. Check out the most
>> recent posts - join the conversation now. http://goparallel.sourceforge.net/
>
>