Merge pull request #120 from epics-containers/april-update

April update

Author: gilesknap

.github/pages/make_switcher.py

@@ -60,8 +60,7 @@ def write_json(path: Path, repository: str, versions: str):
         # Only add the repo name if it isn't the source for the org pages site
         pages_url += f"/{repo_name}"
     struct = [
-        {"version": version, "url": f"{pages_url}/{version}/"}
-        for version in versions
+        {"version": version, "url": f"{pages_url}/{version}/"} for version in versions
     ]
     text = json.dumps(struct, indent=2)
     print(f"JSON switcher:\n{text}")

docs/explanations/changes.md

@@ -6,7 +6,7 @@ Pledge
 
 This page represents a pledge to control breaking changes for users of `epics-containers`. The framework is still under development and there still may be breaking changes in future updates. However we now have a mechanism in place to allow users to adopt the framework, take advantage of the current features and then accept future updates in a controlled fashion.
 
-From version 3.4.0 onwards we will endeavour to make changes in a controlled fashion that obeys SemVer 2.0.0 rules. We will also try to ensure that it is possible to apply updates in a gradual manner and not require a blanket update.
+From version 3.4.0 onwards we will make changes in a controlled fashion that obeys SemVer 2.0.0 rules. We will also ensure that it is possible to apply updates in a gradual manner and not require a blanket update.
 
 The [](../reference/changelog.md) will give details of any things to be aware of between versions, including minor version updates.
 

docs/index.md

@@ -6,6 +6,28 @@ html_theme.sidebar_secondary.remove: true
 :end-before: <!-- README only content
 ```
 
+Update for April 2024 - version 3.4.0
+-------------------------------------
+
+We have just completed another major overhaul of the epics-containers framework. The primary goal of these changes was to add in support for RTEMS based "hard" IOCs. But we have also taken the opportunity to make some other improvements.
+
+"Hard" IOC support is currently limited to the VME5500 processor card running RTEMS 5. However this is a proof of principle for an approach that could be extended to any other type of IOC that cannot run inside of a container. In brief:
+
+- At container build time the IOC binary is cross compiled.
+- The developer image is kept (in container registry) as an archive of the sources that built the binary
+- The runtime image holds the binary only and is based on a 'proxy' image
+- At runtime, the proxy container places the binaries in a location accessible to the hard IOC
+- The proxy container connects to the 'hard' IOC console and may change config to point the bootloader at the new binaries
+- The proxy container reboots the 'hard' IOC
+- The proxy container attaches the IOC console to its stdout/stdin
+- Now the proxy container can be managed/logged/monitored exactly like a linux IOC
+- We have demonstrated using this approach to locally build and test an RTEMS IOC from a workstation using a vscode developer container.
+
+
+The tutorials are now up to date with these latest changes, although the RTEMS tutorials are still in development.
+
+From this release onwards changes will be done in a controlled manner described in the page [](explanations/changes).
+
 Update for February 2024
 ------------------------
 

docs/tutorials/rtems_ioc.md

@@ -1,7 +1,7 @@
 # RTEMS - Deploying an Example IOC
 
 :::{Warning}
-This tutorial is out of date and will be updated in December 2023.
+This tutorial is out of date and will be updated by June 2024.
 :::
 
 The previous tutorials walked through how to create a Generic linux soft

docs/tutorials/rtems_setup.md

@@ -1,7 +1,7 @@
 # RTEMS - Creating a File Server
 
 :::{Warning}
-This tutorial is out of date and will be updated in December 2023.
+This tutorial is out of date and will be updated in June 2024.
 :::
 
 ## Introduction