I agree that automating the regression tests so that there is a pass/fail
result would be nice, and not that difficult implement should a proper OS
portable framework be designed. The effort to run the tests by hand isn't
large compared to the effort required to do the port. However, the real
befits will amass when it becomes easier to test the software after making
changes and or building new releases.
Jeff
-----Original Message-----
From: Andrew Johnson [mailto:[email protected]]
Sent: Friday, June 10, 2005 9:46 AM
To: EPICS Core Talk
Subject: Re: Open source Real-time Oss / open source OS
NB: This is now a core-talk thread, not tech-talk...
Ralph Lange wrote:
>
> Real time OS problems are no different than other OS problems in terms
> of how and why (not) EPICS is running. It's the same OSI layer that has
> to be implemented for a new OS.
>
> Dalesio, Leo `Bob` wrote:
>
>> It seems that we are diverging on these. It is a little worrisome, as
>> operating system problems are ones that are very difficult to find and
>> fix. It would seem most efficient to limit the number of these that we
>> employ.
This may be somewhat idealistic of me, but...
This is exactly the reason why for quite a while I have been wanting us
to have an _automated_ regression test suite. There should be a whole
series of tests that we can run with one command which checks out that
the OSI layer for the platform it's running on does everything that
iocCore expects it to do, and gives an overall pass/fail result at the
end. (R3.14's libCom/test programs fail several of these requirements
for a test suite.)
Someone who is porting EPICS to a new OS should just have ensure their
code passes that test suite and (if we have sufficient test coverage)
they can be reasonably confident that both iocCore and the CA libraries
will run on the new OS. If they find a problem running EPICS on their
new OS that wasn't caught by our tests, we obviously missed something in
our test coverage or assumptions, and need to write another test to
catch that problem.
That's the theory. In practice, once we've found a problem we tend to
just fix it, and not think about it any more. I guess it's really a
question of the effort involved - there's more effort and pressure to
get something working than there is to ensure it won't happen again for
someone else. This is why commercial companies (and probably NIF too)
employ as many testers as they do, but I don't really expect we'll ever
get that kind of resource level available to us.
Sorry, I guess I'm not really expecting anyone to respond to this, just
forget I ever wrote it...
- Andrew
--
Podiabombastic: The tendency to shoot oneself in the foot.
- References:
- Re: Open source Real-time Oss / open source OS Andrew Johnson
- Navigate by Date:
- Prev:
RE: RTEMS on Diamond Systems Prometheus/ EPICS IOC on eCos 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
- Navigate by Thread:
- Prev:
Re: Open source Real-time Oss / open source OS Andrew Johnson
- Next:
RE: RTEMS on Diamond Systems Prometheus/ EPICS IOC on eCos 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
|