Changes between Version 138 and Version 139 of Developer/OpenProjects

Timestamp:

01/26/10 03:44:27 (14 years ago)

Author:

JoelSherrill

Comment:

/* RTEMS Testing */ Shorten

Developer/OpenProjects

@@ -184 +184 @@
 ways to run them all and decode the results.  In addition, we want to be
 able to run all tests on as many hardware and simulator configurations
-as possible.
-= POSIX Timing Tests =
-
-
-'''Status:''' No active volunteers.
-
-There are very few tests in the RTEMS source base which benchmark the
-POSIX Threading API and other POSIX services.  The first step in this
-project would be to develop POSIX API Timing Tests which test the same
-logical tests cases as the existing Classic API Timing Tests.  After that
-is complete, we would want to see Timing Tests for POSIX specific objects
-such as conditional variables and keys.
-
-RTEMS does not use Timing Tests as much for comparison with other
-operating systems but as a ruler for self-improvement.  Each RTEMS
-version should maintain or exceed the performance characteristics of
-previous versions.
-= Coverage Analysis =
-
-
-'''Status:''' On going effort.
-
-See [wiki:RTEMS_Test_Coverage RTEMS Test Coverage] for current status, ideas, and other information.
-
-This is being taken up as a Google Summer of Code 2009 project by Santosh G Vattam and the updates about this project can be found [http://www.rtems.org/wiki/index.php/Coverage_Analysis here]
-= Add Sixty-Four Bit Timestamps =
-
-
-'''Status:''' Implemented. Needs evaluation on various architectures.
-
-Prior to the RTEMS 4.8 Releases, RTEMS based all timing on clock ticks.
-At each clock tick, the current time of day was updated.  This meant
-that the granularity of all time stamps and statistics on per-thread
-CPU usage were constrained to that of the clock tick.  In RTEMS 4.8.0,
-the lowest level of RTEMS -- the SuperCore (e.g. rtems/cpukit/score)
-was converted to use POSIX ''struct timespec'' as the format for all
-timestamps.  In conjunction with the addition of the ability of a BSP
-to report "nanoseconds since last clock tick", RTEMS could now provide
-nanosecond accurate timestamps and CPU usage statistics.
-
-Unfortunately, performing mathematical operations on ''struct timespec''
-is painful and slow.  This project will consist of the following work:
-
- *  Baseline Testing
-  *  (DONE) Verify all test cases work as baseline.
-  *  Capture execution times of RTEMS Timing Tests on reference hardware.
-  *  Capture sizes of sample tests.
-
- *  (DONE) Add a SuperCore object "ScoreTimestamp".  
-  *  This is an opaque class which will be used by all SuperCore time related functions.
-  *  Includes methods will be provided to convert timespec and other standard time formats to and from ScoreTimestamp.
-  *  RTEMS has a class to operate upon timespec's so this will be implemented in terms of this.
-  *  Direct operations on timespec's will be eliminated throughout RTEMS except as necessary near API calls which operate upon ''struct timespec'' arguments.
-  *  Initial implementation will be using ''struct timespec'' and all methods should be simple pass throughs or wrapper of existing functionality in the Timespec math helper class. Note that by adding the class "ScoreTimestamp", we have added a class whose implementation can be changed.
-
- *  (DONE) Verify all existing test cases still work.
-
- *  (DONE) Implement alternate version of SuperCore object "ScoreTimestamp" which uses unsigned sixty-four bit integers to represent nanoseconds since the POSIX epoch.
-  *  This implementation should be fairly simple as you can do direct math on 64-bit integers.
-  *  Do not destroy ''struct timespec'' alternative.  The goal is to be able to pick the implementation is for each port to a new CPU architecture to select its preferred method.
-  *  Provide configuration similar to other configure/build time parameters in RTEMS to let user select implementation.
-  *  Make sure both implementations work. :-D
-
- *  Post Testing
-  *  Verify all test cases work as they did baseline.
-  *  Capture execution times of RTEMS Timing Tests again on reference hardware for both implementations.
-  *  Capture sizes of sample tests.
-
- *  Select proper implementation for each target architecture
- *  Evaluation
-  *  We anticipate that most of the target architectures RTEMS supports will benefit from using the 64-bit integer version.  But RTEMS supports over a dozen architectures so this is certainly not guaranteed.
-  *  Work with RTEMS Community to run tests on as many targets as possible to decide which is best choice on each architecture.
-  *  Simulators are available for most of the primary target architectures so we will be able to judge the impact of your work.
-= Test POSIX FIFOs =
-
-
-'''Status:''' Implemented.  Needs configuration support and tests.
-
-Implement POSIX (named) FIFOs and (unnamed) Pipes.  See [wiki:Projects/POSIXFIFOs POSIXFIFOs] for technical details.
-
-Most of the core RTEMS developers are potential resources here. See cpukit/libfs/src/pipefs for details and contact information.
-= Implement Functionality Currently Missing in dup =
-
-
-'''Status:''' No active volunteers.
-
-Identify and implement missing file descriptor ''dup()'' cases.
+as possible.  Some of the identified activities which would augment our
+testing capabilities are listed here:
+
+ *  [wiki:TBR/Delete/POSIXTimingTests  POSIX Timing Tests] 
+ *  [wiki:RTEMS_Test_Coverage  Test Coverage Analysis]  is an important area in RTEMS.
+ *  [wiki:Projects/SixtyFourBitTimestamps  Add Sixty-Four Bit Timestamps] 
+ *  Test [wiki:Projects/POSIXFIFOs  POSIX FIFO Implementation].
 = Development Environment Oriented =