<div dir="ltr">Great work and thanks for the report!<div><br></div><div>I anticipate that we will switch to your new build system after 5.x is released but that is a community discussion and decision.</div><div><br></div><div>Can you quickly remind us all what is needed so a source file can be considered pre-qualified? Are all of required artifacts and requirements traceability (e.g. requirements coverage) generated?</div><div><br></div><div>Is there any code coverage as part of this?</div><div><br></div><div>No complaints. I just want to make sure I understand and it is clear to others.</div><div><br></div><div>--joel</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Apr 17, 2020 at 8:54 AM Sebastian Huber <<a href="mailto:sebastian.huber@embedded-brains.de">sebastian.huber@embedded-brains.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello,<br>
<br>
for the ESA pre-qualification activity we would like to have an RTEMS <br>
build which includes the pre-qualified parts and in addition give <br>
applications the option to use most of the remaining functionality <br>
provided by a standard RTEMS (excluded are POSIX signals and timers). To <br>
achieve this I wrote a new build system for RTEMS based on specification <br>
items last year as a task of this ESA activity. The RTEMS Project <br>
decided to not integrate it in RTEMS 5 and postpone this to RTEMS 6 <br>
(maybe). To avoid further delays in the ESA activity I decided to start <br>
with the modifications for a pre-qualified build on top of the not yet <br>
integrated new build system.<br>
<br>
I can now build an RTEMS sparc/leon3 BSP which provides potentially <br>
pre-qualified start.o, librtemsbsp.a, librtemscpu.a, and librtemstest.a <br>
artifacts. It offers the full set of RTEMS header files and provides <br>
librtemsbspextra.a, librtemscpuextra.a, librtemstestextra.a, etc. <br>
libraries as non-pre-qualified components. In the build specification, <br>
every header and source file belongs exactly one of two pairwise <br>
disjoint sets (pre-qualified and non-pre-qualified). The source and <br>
header files necessary for the pre-qualified artifacts are determined by <br>
the new space profile validation test:<br>
<br>
<a href="https://git.rtems.org/sebh/rtems.git/tree/testsuites/validation/ts-profile.c?h=qual" rel="noreferrer" target="_blank">https://git.rtems.org/sebh/rtems.git/tree/testsuites/validation/ts-profile.c?h=qual</a><br>
<br>
This test includes all functions of the space profile proposal (except <br>
device drivers and the interrupt controller API).<br>
<br>
<a href="https://ftp.rtems.org/pub/rtems/people/sebh/tn-space-profile-r2-18072019.pdf" rel="noreferrer" target="_blank">https://ftp.rtems.org/pub/rtems/people/sebh/tn-space-profile-r2-18072019.pdf</a><br>
<br>
In the pre-qualified set of files for sparc/leon3, there are 242 header <br>
files, 255 C source files, and 8 assembler source files.<br>
<br>
The pre-qualified set has no reference to the heap free function. To <br>
achieve this, I wrote more than a hundred patches for RTEMS in 2019 and <br>
2020 (thanks for reviewing all this stuff and all the help to find <br>
better solutions). A change in the space profile is necessary for this <br>
also. We have to replace the rtems_task_create() function with an <br>
rtems_task_build() function. This needs to be discussed:<br>
<br>
<a href="https://devel.rtems.org/ticket/3959" rel="noreferrer" target="_blank">https://devel.rtems.org/ticket/3959</a><br>
<br>
The application configuration using the pre-qualified artifacts is done <br>
through the standard <rtems/confdefs.h> header file. To achieve this, I <br>
had to rework a nearly 4k lines of code header file. I split it into 22 <br>
different header files:<br>
<br>
<a href="https://git.rtems.org/rtems/tree/cpukit/include/rtems/confdefs" rel="noreferrer" target="_blank">https://git.rtems.org/rtems/tree/cpukit/include/rtems/confdefs</a><br>
<br>
All 149 application configuration options are now documented and <br>
(partly) specified:<br>
<br>
<a href="https://git.rtems.org/sebh/rtems-qual.git/tree/spec/acfg/opt" rel="noreferrer" target="_blank">https://git.rtems.org/sebh/rtems-qual.git/tree/spec/acfg/opt</a><br>
<br>
How can we verify which source and header files are required for the <br>
space profile? For this I added a verification build. All files of the <br>
pre-qualified set are copied to a separate directory, then a build of <br>
only the pre-qualified artifacts is done in this separate directory <br>
using the build specification of the corresponding RTEMS sources. Only <br>
the artifacts and header file in this separate directory are used to <br>
link the space profile validation test. You can install this build and <br>
get a BSP installation without the extras. Doing this specialized build <br>
is done with 11 lines of Python code. Gathering the files necessary for <br>
this build is done with 57 lines of Python code. You find it here:<br>
<br>
<a href="https://git.rtems.org/sebh/rtems-qual.git/" rel="noreferrer" target="_blank">https://git.rtems.org/sebh/rtems-qual.git/</a><br>
<br>
The specification items are in YAML format. I am very happy with this <br>
file format, however, the Python YAML parser is quite slow. So, I wrote <br>
an item cache in Python pickle format. It loads the current <br>
specification (2439 files) in about 0.2 seconds compared to several <br>
seconds if loaded from YAML.<br>
<br>
The code was written according to the new RTEMS Python Development <br>
Guidelines:<br>
<br>
<a href="https://docs.rtems.org/branches/master/eng/python-devel.html" rel="noreferrer" target="_blank">https://docs.rtems.org/branches/master/eng/python-devel.html</a><br>
<br>
The code is formatted by yapf and analyzed by flake8, mypy, and pylint. <br>
It is tested with pytest. The code coverage through unit tests is:<br>
<br>
coverage report -m <br>
--include=rtems_spec_to_x.py,rtemsqual/util.py,rtemsqual/items.py,rtemsqual/__init__.py,rtemsqual/glossary.py,rtemsqual/content.py,rtemsqual/build.py,rtemsqual/applconfig.py<br>
Name Stmts Miss Cover Missing<br>
-------------------------------------------------------<br>
rtemsqual/__init__.py 8 0 100%<br>
rtemsqual/applconfig.py 130 0 100%<br>
rtemsqual/build.py 36 0 100%<br>
rtemsqual/content.py 133 0 100%<br>
rtemsqual/glossary.py 71 0 100%<br>
rtemsqual/items.py 126 0 100%<br>
rtemsqual/util.py 26 0 100%<br>
-------------------------------------------------------<br>
TOTAL 530 0 100%<br>
<br>
I found that using the analyzers helped during development and is not a <br>
burden. I think it improves productivity. You just need to get used to it.<br>
<br>
<br>
_______________________________________________<br>
devel mailing list<br>
<a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a></blockquote></div>