Westernization of RTEMS/stm32H7 [was: Re: Discussion: How to handle HALs, SDKs and libraries]

[oss at c-mauderer.de]

Hello Karel,

Am 16.07.23 um 00:07 schrieb Karel Gardas:
> 
>    Hello,
> 
> Christian mentioned Zephyr west tool as one of good/possible candidates 
> for RTEMS tree modularization especially with regarding to HALs and 
> other 3rd party libraries.

I mentioned it as one of three tools that I know that solve similar 
problems (Google `repo` from Android, `west` from Zephyr and the feeds 
from OpenWRT). And clearly I haven't made clear enough what my goal was:

I don't want to suggest that we jump on a random tool and use that. What 
I wanted is that we take a look at the reasons why the tools exist and 
evaluate whether we - as RTEMS project - have similar problems that have 
been solved with the tool. You wanted to avoid the academic debate in an 
earlier mail, so I didn't start to go into more details of every reason. 
But now there is a second prototype with a different tool so most likely 
we have to compare some more.

West has the best documentation why they created that tool:

   https://docs.zephyrproject.org/latest/develop/west/why.html

R1. Keeping code out of the main repo. That has advantages and 
disadvantages. And I'm not sure what's more important. Main advantage is 
that it makes more clear what is RTEMS and what is some external source. 
  Main disadvantage is most likely that it is a bit more difficult to 
integrate it into the release process. If it's only one repo, the 
release will be to check out the submodules and archive everything as 
one big file. With multiple separate repos, we have to create one file 
for every repo. Additionally, a user has to download all archives to 
build the release version. So most likely that adds complexity.

R2. Tool, that users can use. Depends quite heavily on the workflow and 
use case of the user. RTEMS has a tendency to not adopt new tools 
easily, especially if they have to be used by the end user. So that 
could be a disadvantage.

R3. Allow to override repos in custom distributions. Not sure whether 
that is useful for us as a project.

R4. Continuous tracking of a HEAD or commit-based tracking. Git does the 
commit-based tracking and I already said that I wouldn't be happy about 
continuous tracking of a branch. So that wouldn't be a reason for me.

 From my point of view, what we can learn from that tool is two things:

A) We should take a look whether putting the code in the repo is a 
disadvantage in some situations. I think size of releases and licenses 
could be two. Licenses can be most likely solved with a clear directory 
structure where external libs are in one subdirectory with a good 
description.

B) Do we need to support use cases, where a user wants to replace one 
submodule version by another version without having to create a private 
fork of RTEMS?

C) Do we need to support use cases where we don't want to track fixed 
commit IDs but the HEAD of a branch instead?


For Google repo, I didn't find the original reasons. What I did find are 
some comparisons with submodules like 
https://www.edureka.co/blog/git-submodules-versus-googles-repo-tool

Sounds like the main intention is to make working with multiple repos 
simpler and integrate well with Gerrit and Jenkins. Beneath that, they 
heavily support tracking HEADs of branches.

Main point to learn:

Again: C)

D) We should be careful how we handle submodules so that the usage is as 
simple as possible. So that's part of how we integrate it in our build 
system.

E) We maybe can get problems on a future CI/CD integration.


The OpenWRT Feeds: https://openwrt.org/docs/guide-developer/feeds

I think the main reason why they use that are:

1. Allow to track a HEAD of a branch instead of a certain commit ID. Not 
something that I would want for HALs.

2. Allow a user to add additional feeds. That's similar to the point 3 
of `west`.

I think the main point to learn is basically the same as B) and C).

Best regards

Christian


> 
> For comparison with my previous git submodulization of RTEMS/stm32H7 
> I've also westernized the same in a similar way. Yes, it is intended to 
> remove CMSIS v4 *just* to proof compilation is working with CMSIS 5 from 
> outside module! This is just dirty PoC nothing more. A tree structure 
> looks a bit different as (folowing zephyr example) I keep modules 
> outside the rtems tree. Hence result for west init command below is tree:
> 
> modules/hal/stm32h7/stm32h7xx_hal_driver
> modules/hal/stm32h7/cmsis_device_h7
> modules/hal/stm32h7/CMSIS_5
> rtems/...
> 
> 
> So if you like to see thing, then install west:
> 
> $ pip3 install --user west
> $ export PATH=$PATH:$HOME/.local/bin
> 
> go into some testing directory and:
> 
> $ west init -m https://github.com/karelfv/rtems --mr 
> rtems-west-stm32h7-hal rtems-workspace
> 
> $ cd rtems-workspace/
> $ west update
> 
> Compilation again produces working samples. In comparison with git 
> submodule approach I find west a bit more civilized (user friendly). 
> Nothing is shooting in my own feet etc.
> 
> What may resonate in RTEMS devs is:
> 
> - yaml format for module configuration
> - west implemented in python3
> - west extensible
> 
> It probably will not be big issue to implement custom:
> 
> - west bsplist
> - west bspdefaults
> - west configure
> - west build
> 
> which would just delegate to waf for actual work if needed...
> 
> Comments welcome!
> 
> Karel
>