Genodepkgs November update
A summary of changes in the past couple of months:
The native Dhall interpreter for Genode is close to compliance with the language spec, but due to performance problems with the parser, this sub-project is temporarily stalled. The library can be used to construct and normalize expressions programatically, but parsing code is currently too slow to comfortably generate configuration. De-emphasizing dynamically generated configuration means more focus building on static systems defined using the traditional NixOS method.
The Genode init system has been patched to accept a slightly different configuration schema than the upstream init. This change removes wildcard rules for routing RPC services between components. These rules were in place to make init configurations more ergonomic to manually describe, but with a sufficiently powerful DSL these are no longer needed. This change somewhat reduces the complexity of the init schema system and makes configurations easier to manually audit. At some point it may be practical to replace the init component for something that accepts a more Nix-friendly configuration schema, but not within a foreseeable future. Note that this init cannot appropriately be compared to systemd - systemd is +300KLOC and the Genode init is around 10KLOC, including libraries.
The LLD linker has been patched to link libraries by absolute path, that means that rather than use references like "libcrypto.so", ELF artifacts will refer to full paths such as "/nix/store/…-openssl-1.1.1g-x86_64-unknown-genode/lib/libcrypto.so". This explicitly establishes what the runtime dependencies of a binary are and optimizes loading times. Note Genode loads libraries externally, the loader parses the ELF header locally then makes an RPC requests by library name for a memory region containing the library. The libraries are then loaded from the file-system by a dedicated component that manages a cache of binaries and libraries. Linking libraries by absolute path as a general policy within Nixpkgs has been proposed, but has not been implemented. Genode makes this much easier by bypassing the libc during loading.
Link to libraries through absolute paths?
The biggest update is the transition from a custom test framework to simply adopting the NixOS module system for building test systems. There are now NixOS modules that define which kernel to boot from and a hardware module that configures drivers and IP stacks to coincide with standard NixOS parameters.
I am currently working on translating systemd services to Genode init children. This is achievable in simple cases by extracting "config.systemd.services.….service.serviceConfig.ExecStart" and requiring a few extra parameters. In a simple example this currently looks like this:
Systemd translation is still a work in progress.
You might wonder what form the Nix store takes in such a system. Currently a store closure is collected from the system configuration and packaged as a tarball. This tarball is bundled with the initial binaries that are used to bootstrap the system and is passed to the Genode core component from the bootloader via the kernel. Sub-systems may access this store tarball by a read-only file-system RPC session or using the ROM loading RPC. The entire Nix store is available to each client component, but hosting multiple store instances will soon become practical.
The current systems I'm able to build are similar to a Linux system that hasn't booted beyond an initramfs. When I'm able to successfully translate systemd services I will add block-device drivers and file-systems, as well as a framebuffer for log output.
Hydra / CI
My Hydra is gone I need to arrange for a new one. If anyone can donate some Hydra time, please let me know. Being without a Hydra unfortunately means that the Sotest hardware tests have also stopped.
There is now a Cachix cache that contains the custom toolchains and many of the packages:
I will keep working on translating existing NixOS configurations until at least the next update. Without proper documentation it would be difficult for additional contributors to get accustomed to working within the repository, however, if anyone would like to get involved and has a specific system they would like to build, I'd be happy to assist, and it would help me streamline the development processes.