Revolutionizing EPICS Module Configuration for Better Efficiency
"Explore the innovative approaches implemented by PSI to streamline EPICS module configuration, reducing maintenance burden and enhancing scalability. From dynamic loading to custom build configurations, discover the future of EPICS development. Presented by Simon Rose on 2024-09-17."
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
The once and future require Optional subtitle PRESENTED BY SIMON ROSE 2024-09-17
Agenda 1 PSI s require 2 e3 (and conda) 3 The dream 4 The takeaway 2025-03-20 PRESENTATION TITLE/FOOTER 3
1 PSI s require The library in the IOC
From PSI What was require? require was created at PSI as an EPICS module that can dynamically load EPICS modules at IOC startup* This allows IOC configuration to be handled by startup scripts instead of compilation and static/dynamic linking 2025-03-20 PRESENTATION TITLE/FOOTER 5
From PSI Do you like makefiles? The caveat is that the modules must be built in a special way This involves an amazing makefile that calls itself recursively four times to determine among other things Which versions of EPICS base to build for Which architectures Which files and then build them This makefile is impressive, but maintenance is a burden 2025-03-20 PRESENTATION TITLE/FOOTER 6
2 e3 (and conda) The queen of NFS and artifactory
e3! Makefile explosion! The PSI way (and initial way at ESS) to build modules required exploding the modules out into separate files and then running make with this complicated makefile Also requires an additional custom build config on a per-module basis Looks sort of like a CMakeLists.txt file The brilliant idea of e3 was that we should separate our custom build configuration from the actual code being built 2025-03-20 PRESENTATION TITLE/FOOTER 8
e3! Conda! Wrappers, recipes, fight. Two ways have been used Wrappers: link the source as a git submodule, include extra configuration and metadata, and install over NFS Conda recipes: Similar, but a bit thinner. Distribute packages in a shared artifactory 2025-03-20 PRESENTATION TITLE/FOOTER 9
e3! Conda! Danger! Separation of powers Both mechanisms ultimately separate the community code from the site- specific build configuration Both mechanisms, however, still use l e M r r d v . k e f 2025-03-20 PRESENTATION TITLE/FOOTER 10
e3! Conda! Danger! Why? No, seriously. Hard to follow. Big downsides: driver.Makefile = hard to follow EPICS modules already include build configuration; why do we need to duplicate it? 2025-03-20 PRESENTATION TITLE/FOOTER 11
3 The dream The ill-made build system
Packages are key But whyyyyyy do we have to duplicate everything The wrapper idea is great Standard packaging of modules is lovely Dynamic loading simplifies a lot of configuration Why can t we just do that with the standard EPICS build rules? 2025-03-20 PRESENTATION TITLE/FOOTER 13
Yes we can! Vote e3 2024 Developed a proof-of-concept version of require that: Does not use driver.makefile Adds some custom CFG files instead Depending on which require this is -1214 or -758 lines, and +54. Not bad! 2025-03-20 PRESENTATION TITLE/FOOTER 14
Nothing new to see here RELEASE the hounds Some metadata is of course required for modules. But this tends to consist of Overwriting/Patching RELEASE Patching CONFIG_SITE(.local) Some module-specific changes you would do anyhow (e.g. don t build tests, specify dbd files, etc.) Basically, nothing you weren t doing anyhow 2025-03-20 PRESENTATION TITLE/FOOTER 15
So how does it work? EPICS build system is wild Basically adds a TOP_RULES_REQUIRE file Did you know you can do this? It s cool! There is also a DIR_RULES_* option to do other creative things This adds a few rules that take the installed output, and copy some of the directories as a package Also creates the famous .dep file that describes what modules need to be loaded first That s it 2025-03-20 PRESENTATION TITLE/FOOTER 16
4 The takeaway The registerAllRecordDeviceDrivers in EPICS base
So why should you care? Dynamism Using dynamic loading makes for very simple configuration of IOCs. They re text files! Tastes great with: Git Ansible CI/CD Various monitoring tools 2025-03-20 PRESENTATION TITLE/FOOTER 18
So why should you care? Standards Until now the buy-in has been a bit rough; require adds a lot of complexity both when setting things up to build and when building Our wrappers/recipes are half of that already, but still a lot of work to contribute to Debugging and maintenance is hard (trust me!) This replaces it with relatively standard config and straightforward additions to EPICS base 2025-03-20 PRESENTATION TITLE/FOOTER 19
So why should you care? Optimism Extremely compatible with generic IOC concept Literally uses softIocPVA, the most generic IOC In the best of all worlds, allows for an IOC environment using standard tools that is Replicable Configurable 2025-03-20 PRESENTATION TITLE/FOOTER 20
