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.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
