RTEMS Pre-Qualification Status

[Sebastian Huber]

Hello,

I would like to give a status report about the RTEMS pre-qualification 
activity and an outlook to the work ahead. Since my last report in July 
this year

https://lists.rtems.org/pipermail/devel/2020-July/060566.html

a lot happened in the RTEMS Project. The RTEMS specification repository 
is now included in the set of RTEMS Project repositories:

https://lists.rtems.org/pipermail/devel/2020-July/060914.html

One goal of the RTEMS specification is to establish a centralized data 
set which can be used to generate source code and documentation sources 
for the referenced modules (RTEMS sources and documentation).

The RTEMS 5.1 release in August

https://lists.rtems.org/pipermail/users/2020-August/067811.html

made it possible to integrate the first bigger chunks of work resulting 
from the pre-qualification activity.

Firstly, the new build system was integrated:

https://git.rtems.org/rtems/commit/?id=f3f0370f1054f4e49aa8f5ea70485d673e8e94b6

The development of the new build system started in August 2019 and was 
basically finished in November 2019. The new build system uses 
specification items which can be re-used in the RTEMS pre-qualification 
activity:

https://docs.rtems.org/branches/master/eng/req/items.html#spectypebuilditemtype

Secondly, two new directives are now available: rtems_task_construct() 
and rtems_message_queue_construct(). The key feature of these two 
directives is that they use user-provided instead of system-provided 
storage to construct the object. This makes it possible to build 
applications which use only statically allocated storage and do not use 
the RTEMS Workspace. This helps to implement the so called space profile 
subset of RTEMS. The space profile was determined by a user survey last 
year:

https://lists.rtems.org/pipermail/users/2019-March/032977.html

The specification, validation, and documentation of these two new 
directives is still incomplete, however, they already give a proof of 
concept of the specification work flow. For example, the Doxygen markup 
and the declarations in the header files are generated from the 
specification. The error cases are specified by action requirements and 
the generated test cases are included in the RTEMS sources along with a 
general purpose validation test suite:

https://git.rtems.org/rtems/tree/testsuites/validation

Thirdly, the first header and documentation files generated from the 
specification are included in the RTEMS sources:

https://git.rtems.org/rtems/tree/cpukit/include/rtems.h#n38

https://git.rtems.org/rtems/tree/cpukit/doxygen/appl-config.h#n31

What are the next steps?

The API defined by <rtems.h> is already fully specified and I can build 
RTEMS and all tests with it. What is missing are the documentation parts 
included in the interface specification. Once this information is 
available in the specification items, we can generate the header files 
with Doxygen markup and the Sphinx documentation sources for the manuals 
from the same data set. For this I have to review the existing 
documentation in the header files and the documentation sources and 
consolidate the information in the corresponding specification items. I 
completed this work already for the Event Manager and the IO Manager and 
will it send soon for review to the RTEMS mailing list. I hope to have 
all managers converted by the end of the year.

Parallel to the interface specification and documentation we work on the 
functional specification of the interfaces and the validation tests. 
This will mostly result in new test cases and test suites.

There are some topics left for the RTEMS Software Engineering manual. We 
had some discussions about the use of static analysis tools in RTEMS. I 
think the results of the discussion should be added to a new chapter or 
section. We should discuss if, which, and how code quality metrics can 
be used in the RTEMS Project.