Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  Index 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020 
<== Date ==> <== Thread ==>

Subject: RE: Open source Real-time Oss / open source OS
From: "Jeff Hill" <johill@lanl.gov>
To: "'EPICS Core Talk'" <core-talk@aps.anl.gov>, "'Andrew Johnson'" <anj@aps.anl.gov>
Date: Fri, 10 Jun 2005 12:29:36 -0600
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:anj@aps.anl.gov] 
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  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020 
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  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020 
ANJ, 02 Feb 2012 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·