Version 4 (modified by Gedare Bloom, on Sep 12, 2018 at 7:24:45 PM) (diff)


Create a POSIX Timing Test

Directions for Students

Pre-Requisite: You must have completed the "Getting Started: Hello World" task or equivalently done the GSoC Getting Started Guide before attempting this task.

Invoking rtems-testing/rtems-test-template/mktest

To create a test, you'll need to be in the rtems/testsuite/your_pattern directory. This task consists of adding a benchmark test to the RTEMS POSIX Timing Test Suite. There are templates for each benchmark pattern we have identified. The task consists of identifying the correct pattern, instantiating it using the "mktest" script, and then filling that in with the appropriate calls. For example:


You'll need to specify the source (-s), the destination (-d), and the test number (-n). Change the location to match where you put rtems-testing. For example:

 ~/rtems/testsuites/psxtmtests> ~/rtems-testing/rtems-test-template/mktest \
 -s ~/rtems-testing/rtems-test-template/psxtmtest_unblocking_preempt \
 -d psxtmcond04 \
 -n 4

Adding the Test to the Build System

To add a test to the build system, you'll need to add it to and Then you'll need to ./bootstrap it.

Changes to


  SUBDIRS += psxtmthread01
  SUBDIRS += psxtmthread03
  SUBDIRS += psxtmcond04 # Add a SUBDIRS entry to the bottom

Changes to



Now bootstrap it

 cd ~/rtems
 ~/rtems> ./bootstrap

Now build...

 cd ../b-sis
 ../rtems/configure --options --used --to --configure

Finding an Example

Now that the test has been added to the build system, find working examples of the functions to call. One way to do that is to use grep -r. From the terminal, there may be characters that have to be "escaped" \. For example to create a test of pthread_cond_init() put the following in the command line:

 grep -r pthread\_cond\_init ~/rtems/testsuites/


Finally use a simulator/emulator See

Lather, Rinse, Repeat

Add all the #includes, at the top, compare the macros at the bottom, cut-and-paste from working example of the source code into the generated test, see what happens.

After each change, clean the build directory, rebuild the source, and try again, depending on the simulator something like:

 ~/b-sis make clean
 ~/b-sis ../rtems/configure --options --to --configure
 ~/b-sis make
 ~/b-sis sparc-rtems4.11-gdb `find . -name ticker.exe`

This is a particularly challenging task, so asking questions, and making suggestions for improving the directions on this task would be greatly appreciated.

Posix Time Test Plan (for generating more GCI tasks)

This task can be instantiated for multiple areas in POSIX but the following is a typical set for communications and synchronization objects. A GSOC 2011 project implemented many tests for semaphores, message queues, etc., but there are still many left to implement. The following is a link to the Comma Separated Value (e.g., .csv) file which is exported from the spreadsheet used to track the status of this effort.

There are likely 50-100 instances of this task possible.

Directions for Mentors

This should be evaluated as a normal code submission. You need to review and run the test to ensure it is correct. It should be based upon the templates in rtems-testing. The student should provide a name and email for proper attribution. If you have write permission, commit it. Otherwise, send it to rtems-devel for another developer to commit with commentary indicating it is acceptable and from GCI.