Changes between Version 11 and Version 12 of Developer/SmallProjects


Ignore:
Timestamp:
11/23/14 06:49:56 (9 years ago)
Author:
Chris Johns
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Developer/SmallProjects

    v11 v12  
    1313
    1414 *  Improve the Wiki (requires Wiki editing)
    15   *  [wiki:BoardSupportPackageInformation_ BSPs]: There are approximately 100 boards supported by RTEMS.  Each board has a page in the Wiki and there is an standard Wiki Infobox. Most BSPs still do not have any information here, links to vendor information, or even a good description of the board.  This effort just requires a bit of web research.
     15  *  [wiki:TBR/Website/Board_Support_Packages BSPs]: There are approximately 100 boards supported by RTEMS.  Each board has a page in the Wiki and there is an standard Wiki Infobox. Most BSPs still do not have any information here, links to vendor information, or even a good description of the board.  This effort just requires a bit of web research.
    1616  *  [wiki:Developer/OpenProjects Open Projects]: Create a template and prioritization for adding/updating open projects. See [wiki:TBR/Review/OpenProjectTemplate OpenProjectTemplate]. Update all projects.
    1717
     
    3838  *  There is a continual need for more test code.   We would like a timing test suite for the POSIX thread support that is comparable to the current Classic API timing test suite.  We expect this will eventually comprise about 50 different tests so could be tackled as a class project with the individual tests assigned to different people or groups.
    3939
    40   *  Write tests to improve [wiki:RTEMS_Test_Coverage  Test Coverage].  We want full object coverage for as much of RTEMS as possible.  In this light, there are areas which are under tested in the automated test suite.  This is an ongoing project with a variety of areas that need test cases written.  Please ask for a current coverage report and a recommended area you can tackle.
     40  *  Write tests to improve [wiki:Projects/TestingImprovements  Test Coverage].  We want full object coverage for as much of RTEMS as possible.  In this light, there are areas which are under tested in the automated test suite.  This is an ongoing project with a variety of areas that need test cases written.  Please ask for a current coverage report and a recommended area you can tackle.
    4141
    42  *  Add example uses of each Manager to User's Guide.  The C User's manual for the Classic API currently does not include example uses.  One part of this is letting readers know that counting semaphores may be used to manage a pool of resources and binary may be used for mutual exclusion or condition synchronization.  But the other part is moving it beyond the theoretical to show code and give examples of how this might be used in a real application.  For example, condition synchronization with binary semaphore to announce that an interrupt occurred to a waiting task. = Investigate GCC Test Failures =
     42 *  Add example uses of each Manager to User's Guide.  The C User's manual for the Classic API currently does not include example uses.  One part of this is letting readers know that counting semaphores may be used to manage a pool of resources and binary may be used for mutual exclusion or condition synchronization.  But the other part is moving it beyond the theoretical to show code and give examples of how this might be used in a real application.  For example, condition synchronization with binary semaphore to announce that an interrupt occurred to a waiting task.
     43= Investigate GCC Test Failures =
    4344
    4445
     
    4647
    4748The GCC C, C++, and Ada test suites are regularly run on multiple architectures using simulators.  All RTEMS tools tests reports are archived at [http://www.rtems.org/pipermail/rtems-tooltestresults/] as well as at [http://gcc.gnu.org/ml/gcc-testresults].  Pick the latest test result for your favourite target architecture and start looking at the failure cases. 
    48 # Make sure there isn't a PR for it already.  If there is, update it to note the failure is still occurring.
    49 # Check out the gcc-testing CVS modules from the RTEMS CVS repository and follow the instructions to build and run the tests yourself.
    50 # Pick a test that fails and investigate it
    51 ## Some "scan assembler" tests fail because RTEMS tests are run on a particular BSP which uses specific CPU model compile options which may conflict with the CPU model the instructions would be generated on. 
    52 ## Others may core dump.  Try to get a stack backtrace in gdb.
    53 ## Check that the stack isn't blown or that it isn't using too much memory for the BSP.  It may be "expected to fail" on this BSP.
    54 # In all cases, file a PR at [http://gcc.gnu.org/bugzilla] so your explanation is captured.
    55 # If you can provide a patch, try.  Fixing test infrastructure issues is generally easier than fixing code generation problems.
     491. Make sure there isn't a PR for it already.  If there is, update it to note the failure is still occurring.
     501. Check out the gcc-testing CVS modules from the RTEMS CVS repository and follow the instructions to build and run the tests yourself.
     511. Pick a test that fails and investigate it
     52 a. Some "scan assembler" tests fail because RTEMS tests are run on a particular BSP which uses specific CPU model compile options which may conflict with the CPU model the instructions would be generated on. 
     53 a. Others may core dump.  Try to get a stack backtrace in gdb.
     54 a. Check that the stack isn't blown or that it isn't using too much memory for the BSP.  It may be "expected to fail" on this BSP.
     551. In all cases, file a PR at [http://gcc.gnu.org/bugzilla] so your explanation is captured.
     561. If you can provide a patch, try.  Fixing test infrastructure issues is generally easier than fixing code generation problems.