mirror of
https://git.rtems.org/rtems-docs/
synced 2025-10-18 21:02:37 +08:00
user/hardware/tiers.rst: Merge info from Wiki.
Tiers had a write up on the Wiki which was similar but different. Merged content from the Wiki which allows the Wiki page to be deleted. closes #3831.
This commit is contained in:
@@ -14,9 +14,32 @@ RTEMS has a tiered structure for architecture and BSPs. It provides:
|
|||||||
|
|
||||||
#. A quaility measure for changes entering the RTEMS source code.
|
#. A quaility measure for changes entering the RTEMS source code.
|
||||||
|
|
||||||
|
The RTEMS project supports RTEMS Architecture Tiers. Each architecture
|
||||||
|
resided in one of the numbered tiers. The tiers are number 1 to 4 where
|
||||||
|
Tier 1 is the highest tier and Tier 4 is the lowest. Architectures move
|
||||||
|
between tiers based on the level of support and the level of testing that
|
||||||
|
is performed. An architecture requires continual testing and reporting
|
||||||
|
of test results to maintain a tier level. The RTEMS Project's continuous
|
||||||
|
integration testing program` continually monitors and reports the test
|
||||||
|
results.
|
||||||
|
|
||||||
|
The RTEMS Architecture Tier system provides a defined way to determine
|
||||||
|
the state of an architecture in RTEMS. Architectures age and support
|
||||||
|
for them drops off and the RTEMS Project needs a way to determine
|
||||||
|
if an architecture should stay and be supported or depreciated and
|
||||||
|
removed. The tier system also provides users with a clear understanding of
|
||||||
|
the state of an architecture in RTEMS, often useful when deciding on
|
||||||
|
a processor for a new project. It can also let a user know the RTEMS
|
||||||
|
Project needs support to maintain a specific architecture. Access to
|
||||||
|
hardware to perform testing is a large and complex undertaking and the
|
||||||
|
RTEMS Project is always looking for user support and help. If you can
|
||||||
|
help please contact someone and let us know.
|
||||||
|
|
||||||
The tier structure in RTEMS is support by the Buildbot continuous integration
|
The tier structure in RTEMS is support by the Buildbot continuous integration
|
||||||
server. Changes to RTEMS are automatically built and tested and the results
|
server. Changes to RTEMS are automatically built and tested and the results
|
||||||
indicate if a BSP currently meets it's tier status.
|
indicate if a BSP currently meets its tier status. As the RTEMS Project
|
||||||
|
does not own hardware for every BSP, it is critical that users provide
|
||||||
|
test results on hardware of interest.
|
||||||
|
|
||||||
The rules for Tiers are:
|
The rules for Tiers are:
|
||||||
|
|
||||||
@@ -43,11 +66,11 @@ The rules for Tiers are:
|
|||||||
|
|
||||||
#. The tier level for a BSP is set by the RTEMS Project team. Movement of BSP
|
#. The tier level for a BSP is set by the RTEMS Project team. Movement of BSP
|
||||||
between tier level requires agreement. The Buildbot results indicate the
|
between tier level requires agreement. The Buildbot results indicate the
|
||||||
current tier level.
|
minimum current tier level.
|
||||||
|
|
||||||
#. Changes to RTEMS may result in a BSP not meeting it's tier are acceptable if
|
#. Changes to RTEMS may result in a BSP not meeting its tier are acceptable if
|
||||||
the change is accompanied by an announcement and a plan on how this is to be
|
the change is accompanied by an announcement and a plan on how this is to be
|
||||||
resolved.
|
resolved. Temporary drops in tier are expected and should be brief.
|
||||||
|
|
||||||
#. Test results are set on a per BSP basis by the RTEMS Project team. Changes
|
#. Test results are set on a per BSP basis by the RTEMS Project team. Changes
|
||||||
to the test result values requires agreement. The test results are defined
|
to the test result values requires agreement. The test results are defined
|
||||||
@@ -58,4 +81,4 @@ The rules for Tiers are:
|
|||||||
#. Expected Failures
|
#. Expected Failures
|
||||||
|
|
||||||
Expected failures must be explicitly listed. A BSP is required to have a
|
Expected failures must be explicitly listed. A BSP is required to have a
|
||||||
valid test result entry to reach tier 1.
|
valid test result entry on target hardware to reach tier 1.
|
||||||
|
Reference in New Issue
Block a user