I’ve recently become interested in understanding how programs that are downloaded and later executed are handled by the system. Specifically, the storage format of such programs and the mechanism by which a stored file is loaded from memory and executed remain unclear to me. (In fact, the entire process of program execution in this system is still somewhat vague to me.) I have not found a thorough explanation of these concepts in the official genode documentation.
If possible, I would greatly appreciate any guidance whether through direct references to relevant parts of the source code or links to detailed documentation that explains how this execution workflow is implemented.
The installation and deployment of programs within Sculpt OS was introduced inherently by its initial version back in 2018. It is one of the central features that Sculpt OS provides. To ge a first impression, you might read the related release notes part of that time:
It includes diagrams to help understanding the sequence of installation, as well as execution. If you’ve further question outgoing from that, we might try to answer it here.
Genode executables are ELF files. You can find the low-level procedure of creating of a component described at Section 3.5 of the Genode-Foundations book. The corresponding code is located at base/include/base/child.h.
In practice, almost all components are dynamically linked. For such a component, the dynamic linker (base/src/lib/ldso/) is loaded by the code behind the base/child.h API. The dynamic linker, in turn, obtains and locally maps the actual executable “binary” and the corresponding shared-library dependencies before calling the component’s Component::construct function.
The low-level mechanisms provided by base/child.h are hardly ever manually used. Most commonly, components are started via the init component, or the underlying sandbox library, or via the fork implementation provided by the libc.
When I started really dealing with the “nuts and bolts” of the Genode framework, one aspect that I had to wrap my mind around, was the storage of the ELF executable. I was used to the traditional “filesystem-only” storage paradigm, found in other systems. I had to get used to the idea that Genode is much more flexible, anything that can provide a ROM interface with a proper executable, will do.
I even had to write myself a diagram and a few paragraphs to convince myself of it, as well as document some of the finer points I had to deal with when implementing my project. Most of the write-up is BeOS-related, but you’ll find some nuggets of interest to you, like “Genode changes the ROM label to the full path to the library”. HTH.