Discussion: How to handle HALs, SDKs and libraries

[Christian MAUDERER]

Hello,

I recently updated the HAL in the i.MXRT BSP. I used the same approach 
that we use for a lot of similar cases: Import the sources into RTEMS 
and adapt them slightly so that they work for us. So basically a 
Clone-and-Own approach.

During the discussion of the patches, some concerns were raised, whether 
we should find a better solution to handle HALs, SDKs and similar cases. 
We should start discussing a solution that can be used after the 6 
release so that maybe someone can start to work on a prototype.

Some example cases are:

- the mcux_sdk in the imxrt BSP
- the hal in the stm32h7 BSP
- general ARM CMSIS files
- zlib
- libfdt

One solution could be to build these libraries external and only link 
RTEMS with them. There are disadvantages to this aproach:

- Also in my experience, the API of the HALs / SDKs / libraries seems to 
be quite stable, it's possible that there are combinations where some 
unexpected change breaks a driver or makes it impossible to link the 
applications.

- BSPs rely on basic drivers from these libraries (like console or clock 
driver). If we link against the libraries, the testsuite wouldn't build 
any more without preinstalled libraries.

Another solution could be to include libraties like that as submodules 
and build them using the RTEMS build system. We could clone the repos 
onto the RTEMS git server, and add necessary patches. Advantage would be 
that it is more similar to the process that we currently have. Another 
advantage is that we have a known-working version of the files. Upstream 
updates could be either merged or we could rebase our patches to a new 
version.

 From my point of view, the second option would be the better one 
especially because we have a tested, fixed version of the library 
instead telling the user to just use some random version that might or 
might not work.

Regardless which aproach we use: We have to think about how to handle 
that on releases. In the link aproach (first case), we have to somehow 
archive source tar balls and some kind of build recipe. In the submodule 
aproach, we could checkout all submodules and pack the files into the 
RTEMS release tar ball. So I would expect that the second aproach has 
less impact here too.

Comments? Improvements? Better suggestions?

Best regards

Christian
-- 
--------------------------------------------
embedded brains GmbH & Co. KG
Herr Christian MAUDERER
Dornierstr. 4
82178 Puchheim
Germany
email:  christian.mauderer at embedded-brains.de
phone:  +49-89-18 94 741 - 18
mobile: +49-176-152 206 08

Registergericht: Amtsgericht München
Registernummer: HRA 117265
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/