> Having said this, porting EPICS IOC to eCos may not be easy or even
> possible anyway. eCos doesn't have multi-thread safe C++ Standard
> Library support (or at least not out of the box). Is it true the IOC
> software uses C++ STL and Exceptions?
>
We definitely use exceptions. It's pretty hard to avoid exceptions with C++
in practice.
O The default interface to new throws exceptions in ANSI C++, and it's
probably a good bet that someone will use that interface even if project
guidelines were to specify otherwise.
O On some systems you get a C++ exception when there is an arithmetic fault.
O When integrating 3rd party libraries they will, more than likely, use
exceptions.
O With C++, the only way for a constructor to fail out is by throwing an
exception.
> EPICS IOC core does not use C++ standard library routines (Jeff Hill
> can explain why in detail -- I believe the executive summary is that
> the standard library plays too fast and loose with memory
> allocation/deallocation) but does require thread-safe extensions.
Our decision and intent for R3.14 was to not use the STL because, when we
started that effort, there were portability issues. We have inadvertently
introduced a small dependency on std::string resulting from use of some of
the further derived ANSI exception classes. These entanglements probably
could be eliminated simply by not throwing that type of exception class.
You can get some idea of the effort involved by looking at
epics/base/libCom/osi, and by discussing this with Eric - the author of the
RTEMS port.
The decision should however probably be based on whether you feel prepared
to go solo. A standard disclaimer is appropriate. Software is always more
robust when there is a larger installed base. If you are the only site with
a particular OS port then if you experience an issue that no one else sees
you will not have the option of working with other sites to reproduce your
problem in order to find a fix. That means that you should have ready access
to good quality software development (debugging) tools, local system
programmer expertise (people experienced with debugging multi-threaded
programs), and a budget to cover any additional expenses.
I have no doubt that the EPICS community will benefit if you take on the
port. One advantage of multiple ports may be that OS diversity does tend to
uncover implementation problems. Assuming that these problems are fixed, the
software should be more robust to changes introduced as it evolves in the
future. Someone always has to be the first one in the pool.
There is that dilution of effort issue, but I tend to take the optimistic
view that new ports means new users who are willing to help.
Jeff
- Navigate by Date:
- Prev:
Re: Open source Real-time Oss / open source OS Andrew Johnson
- Next:
RE: Open source Real-time Oss / open source OS Jeff Hill
- 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: Open source Real-time Oss / open source OS Jeff Hill
- Next:
meeting in July / ca interface specification 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
|