Replace ipc_bridge with scrample code

This way, EBcLfSA and QNX use the same test code repository for communication.

Author: opajonk

.github/workflows/build_and_test_ebclfsa.yml

@@ -31,11 +31,11 @@ jobs:
         uses: actions/checkout@v4
 
       - name: Build for EB corbos Linux for Safety Applications and run tests
-        run: bazel build --config=aarch64 --spawn_strategy=local //example/ipc_bridge_hi_wrapper:run_example
+        run: bazel build --config=aarch64 --spawn_strategy=local //scrample_sil:run_example
         working-directory: ./ebclfsa
 
       - name: Upload test logs
         uses: actions/upload-artifact@v5
         with:
           name: test-logs
-          path: ebclfsa/bazel-bin/example/ipc_bridge_hi_wrapper/*.log
+          path: ebclfsa/bazel-bin/scrample_sil/*.log

ebclfsa/MODULE.bazel

@@ -19,7 +19,7 @@ module(
     compatibility_level = 0,
 )
 
-bazel_dep(name = "rules_cc", version = "0.2.0")
+bazel_dep(name = "rules_cc", version = "0.2.1")
 
 bazel_dep(name = "score_toolchains_gcc", version = "0.0.0", dev_dependency=True)
 git_override(
@@ -49,7 +49,6 @@ gcc.warning_flags(
 
 use_repo(gcc, "gcc_toolchain", "gcc_toolchain_gcc")
 
-
 bazel_dep(name = "rules_boost", repo_name = "com_github_nelhage_rules_boost")
 archive_override(
     module_name = "rules_boost",
@@ -74,6 +73,10 @@ single_version_override(
     version = "0.1.1",
 )
 
+bazel_dep(name = "score_scrample", version = "0.1.0")
+
+#bazel_dep(name = "score_persistency", version = "0.2.1")
+
 # git_override are not forwarded by bazel_dep, so we need to redefine it here
 git_override(
     module_name = "trlc",

ebclfsa/README.md

@@ -24,7 +24,7 @@ However, please understand that we cannot advise you about possible costs in you
 > - Copy and paste the following command into the terminal and hit "Enter":
 >
 > ```bash
-> cd ./ebclfsa && bazel build --config=aarch64 --spawn_strategy=local //example/ipc_bridge_hi_wrapper:run_example
+> cd ./ebclfsa && bazel build --config=aarch64 --spawn_strategy=local //scrample_sil:run_example
 > ```
 >
 > This will build and run the example.
@@ -35,9 +35,9 @@ However, please understand that we cannot advise you about possible costs in you
 >
 > ```console
 > [...]
-> Target //example/ipc_bridge_hi_wrapper:run_example up-to-date:
->  bazel-bin/example/ipc_bridge_hi_wrapper/qemu_run.log
->  bazel-bin/example/ipc_bridge_hi_wrapper/ssh_run.log
+> Target //scrample_sil:run_example up-to-date:
+>  bazel-bin/scrample_sil/qemu_run.log
+>  bazel-bin/scrample_sil/ssh_run.log
 >INFO: Elapsed time: 361.273s, Critical Path: 91.92s
 >INFO: 836 processes: 10 internal, 826 local.
 >INFO: Build completed successfully, 836 total actions
@@ -214,7 +214,7 @@ The application instances are called with the following arguments:
 Feel free to adjust them as needed.
 
 In order to have those arguments changeable, the HI arguments are not hardcoded into `cflinit`.
-Instead, `cflinit` calls a small wrapper binary `/usr/bin/hi_app` which is based on the implementation in `example/ipc_bridge_hi_wrapper/main.cc`.
+Instead, `cflinit` calls a small wrapper binary `/usr/bin/hi_app` which is based on the implementation in `scrample_sil/main.cc`.
 When `hi_app` is executed by `cflinit`, it simply calls `execve` on `/usr/bin/ipc_bridge_cpp_sil` with the correct set of arguments.
 This way `cflinit` keeps its static entrypoint for the Eclipse S-CORE example app, while the user is still able to specify the used arguments for the HI `ipc_bridge` instance.
 
@@ -234,7 +234,7 @@ With those changes, the toolchain can be used via `bazel build  --config=aarch64
 > [!IMPORTANT]
 > Building inside a sandbox is currently not possible.
 
-For building and running the example setup, the following Bazel rules have been created in `example/ipc_bridge_hi_wrapper/BUILD`:
+For building and running the example setup, the following Bazel rules have been created in `scrample_sil/BUILD`:
 
 | Target | Dependencies | Description |
 | ------ | ------------ | ----------- |
@@ -253,7 +253,7 @@ The following sections introduce some of the rules mentioned above.
 The `run_example` target provides an easy entry point, to build, post-process, deploy, run and stop the example:
 
 ```bash
-bazel build --config=aarch64 --spawn_strategy=local //example/ipc_bridge_hi_wrapper:run_example
+bazel build --config=aarch64 --spawn_strategy=local //scrample_sil:run_example
 ```
 
 This command will take a while to finish, since it performs some downloads and starts the fast-dev image.
@@ -315,7 +315,7 @@ SDK:handler_do_el0_svc_pre: syscall __NR_clone3 (435) is not allowed
 Building all components of the example application can be performed with the `hi_app` rule.
 
 ```bash
-bazel build --config=aarch64 --spawn_strategy=local //example/ipc_bridge_hi_wrapper:hi_app
+bazel build --config=aarch64 --spawn_strategy=local //scrample_sil:hi_app
 ```
 
 Due the dependencies towards `:ipc_bridge_cpp_sil` and `:ipc_bridge_hi_wrapper` this will build all required binaries.
@@ -326,16 +326,16 @@ Including the LI `ipc_bridge_cpp` binary, a temporary `ipc_bridge_hi_wrapper` bi
 The easiest way to setup the fast-dev image, is to use the `fastdev-image` rule.
 
 ```bash
-bazel build --config=aarch64 --spawn_strategy=local //example/ipc_bridge_hi_wrapper:fastdev-image
+bazel build --config=aarch64 --spawn_strategy=local //scrample_sil:fastdev-image
 ```
 
 This will first download the image via the `fetch-fastdev-archive` rule and cache the archive.
-Afterwards, the `fastdev-image` rule extracts the archive (containing a disk image and a kernel) to `bazel-bin/example/ipc_bridge_hi_wrapper/deb-qemuarm64/`.
+Afterwards, the `fastdev-image` rule extracts the archive (containing a disk image and a kernel) to `bazel-bin/scrample_sil/deb-qemuarm64/`.
 
 To start the unmodified base image (without the Eclipse S-CORE example application) manually, the included `run_qemu.sh` script can be used.
 
 ```bash
-./run_qemu.sh bazel-bin/example/ipc_bridge_hi_wrapper/deb-qemuarm64/
+./run_qemu.sh bazel-bin/scrample_sil/deb-qemuarm64/
 ```
 
 This is of course optional, and only needed if a deeper manual look into the image is wished.
@@ -350,19 +350,19 @@ ssh -p 2222 root@localhost
 > [!NOTE]
 > Be aware, that running the image via qemu, will change the stored disk image.
 > Bazel will detect this change and overwrite the disk image with the original one from the downloaded archive.
-> If it is planned to have persistent changes on the image, copy the content of `bazel-bin/example/ipc_bridge_hi_wrapper/deb-qemuarm64/` to a location outside of `bazel-bin` and adapt the command line argument in the above `./run_qemu.sh` call accordingly.
+> If it is planned to have persistent changes on the image, copy the content of `bazel-bin/scrample_sil/deb-qemuarm64/` to a location outside of `bazel-bin` and adapt the command line argument in the above `./run_qemu.sh` call accordingly.
 
-For deploying the example application to the image, the `upload` rule is available, which will start the image based on the content of `bazel-bin/example/ipc_bridge_hi_wrapper/deb-qemuarm64/` and deploy all needed files via `scp`.
+For deploying the example application to the image, the `upload` rule is available, which will start the image based on the content of `bazel-bin/scrample_sil/deb-qemuarm64/` and deploy all needed files via `scp`.
 
 ```bash
-bazel build --config=aarch64 --spawn_strategy=local //example/ipc_bridge_hi_wrapper:upload
+bazel build --config=aarch64 --spawn_strategy=local //scrample_sil:upload
 ```
 
-Since the deployment step will change the stored disk image, the `upload` rule stores its output in `bazel-bin/example/ipc_bridge_hi_wrapper/deb-qemuarm64-modified/`.
+Since the deployment step will change the stored disk image, the `upload` rule stores its output in `bazel-bin/scrample_sil/deb-qemuarm64-modified/`.
 Running the image with the deployed example applications works the same way as before, just with a different folder for the used image and kernel:
 
 ```bash
-./run_qemu.sh bazel-bin/example/ipc_bridge_hi_wrapper/deb-qemuarm64-modified/
+./run_qemu.sh bazel-bin/scrample_sil/deb-qemuarm64-modified/
 ```
 
 Like before you can interact with the image via the serial console or ssh.