=============================================== Release notes for the Genode OS Framework 24.02 =============================================== Genode Labs Version 24.02 focuses on developer experience and framework infrastructure. Genode's Goa SDK has reached prominence in the past few releases. It largely streamlines the porting, development, and publishing of software targeting Genode and Sculpt OS in particular. With the current release, Goa has become able to conveniently use Sculpt OS as a remote test target. Regardless of whether targeting a PC or the PinePhone, either can be turned into a test target in seconds and the developer's compile-test cycle looks exactly the same (Section [Sculpt OS as remote test target for the Goa SDK]). A long anticipated infrastructure topic is the rework of Genode's audio stack to accommodate latency-sensitive scenarios, using flexible sample rates, and making audio drivers pluggable. Section [Revised audio infrastructure] gives an overview of the taken architectural approach, the interfaces, and a low-complexity mixer modelled as self-sufficient resource multiplexer. Speaking of infrastructure, we are excited to report to have wrapped up the transition to our modern Linux device-driver environment based on Linux 6.x. The last piece of the puzzle was the TCP/IP stack that was still based on code originating from Linux 4.4.3. Section [TCP/IP stack based on DDE-Linux version 6.1.20] details the new TCP/IP stack. According to our [https://genode.org/about/road-map - road map], we plan to add suspend/resume as feature to Sculpt OS 24.04. As a crucial stepping stone towards this goal, all drivers that cannot be easily restarted must become suspend/resume aware. Section [Suspend/resume awareness of GPU, AHCI, and NVMe drivers] explains this achievement for the AHCI, NVMe, and Intel GPU drivers. Further highlights of the release are the much improved handling of HID events including the generalized calibration of motion events, API safety improvements, the prospect of de-privileged tracing in Sculpt OS, and multi-client support for Vivante GPUs. On our road map, we had scheduled two further topics that are notably absent, namely USB and SMS. But don't fret. Even though the large rework of our USB infrastructure for fine-grained and dynamic USB access has been completed just in time, we felt that this far-reaching change should better not be rushed into the release. It will be merged shortly after, and settle into the upcoming Sculpt OS version 24.04 just fine. The second topic not covered is SMS support for the PinePhone, which is a topic actively [https://github.com/genodelabs/genode/issues/5127 - worked on] but with no user-visible effect until its integration in Sculpt OS in April. Revised audio infrastructure ############################ After first introduced in version [https://genode.org/documentation/release-notes/10.05#Device-class_interfaces_for_NIC_and_Audio-out - 10.05], Genode's [https://genode.org/documentation/genode-foundations/23.05/components/Common_session_interfaces.html#Audio_output - audio support] slowly evolved over the years, covering audio mixing in version [https://genode.org/documentation/release-notes/10.11#Audio_mixer - 10.11], leveraging OpenBSD's audio driver since version [https://genode.org/documentation/release-notes/15.05#Audio_drivers_ported_from_OpenBSD - 15.05] and offering the OSS interface as VFS plugin since version [https://genode.org/documentation/release-notes/20.11#Streamlined_ioctl_handling_in_the_C_runtime___VFS - 20.11]. With our recent focus on use cases like [https://genodians.org/jws/2023-11-16-sip-client-for-genode - VoIP on the PinePhone] or [https://genode.org/documentation/release-notes/21.05#Webcam_support - video conferencing], however, we identified limitations that cannot be overcome without an architectural revision. First, in the name of simplicity, we used to tie the inter-component audio interfaces to a fixed sample rate of 44100 Hz. This has recently become a problem because some audio drivers tend to support only 48000 Hz. Second, in latency-sensitive scenarios, we observed that the existing interfaces were prone to effects caused by the drifting of time between the producer and consumer of audio data. One effect are buffer under-runs, which produce audible noise. The other is the slow accumulation of buffered sample data, which increases latency over time (affecting the effectiveness of acoustic echo cancellation) and yields an audible buffer overrun after a while. Third, the mixer is a single client of the audio driver, which makes the mixer dependent on the liveliness of the driver. Therefore, the driver cannot be restarted without also restarting the mixer and - transitively - each client of the mixer. The rigid relation between the audio driver and the mixer also stands in the way of routing audio between different audio devices operated by separate drivers. After having successfully introduced the concept of _pluggable drivers_ for graphics in version [https://genode.org/documentation/release-notes/20.08#The_GUI_stack__restacked - 20.08] and applying the same idea to networking in version [https://genode.org/documentation/release-notes/21.02#Pluggable_network_device_drivers - 21.02], the time was ripe for turning the audio infrastructure upside down. [image audio_vs_recordplay] original layered architecture (left) compared to the new pluggable architecture (right) The new architecture as shown on the right turns the mixer into a self-sufficient resource multiplexer, which offers a service for playing audio and a service for recording audio. Both audio drivers as well as audio applications are becoming mere clients of the mixer. With this architecture, the dynamic starting, removal, and restarting of the driver, of even multiple drivers, is trivially solved. To bridge the gap between audio clients operating at different sample rates, the mixer automatically detects and converts sample rates as needed. Both play and record clients are expected to operate periodically. The number of samples produced per period is up to each client and does not need to be constant over time. The mixer infers the used sample rates and periods by observing the behavior of the clients. It measures the jitter of clients to automatically adjust buffering parameters to attain continuous playback while trying to optimize for low latency. Those runtime-measurements can be augmented by explicit configuration values. Multi-channel playing and recording are realized by one session per channel whereas one channel is used to drive the time allocation while all further channels merely enqueue/obtain data into/from their respective sessions without any synchronous interplay with the mixer. The mixer routes and mixes audio signals produced by play clients to record clients according to its configuration. Typical play clients are an audio player or a microphone driver whereas typical record clients are an audio recorder or an audio-output driver. A simple mixer configuration looks as follows: ! <config> ! ! <mix name="left"> <play label_suffix="left"/> </mix> ! <mix name="right"> <play label_suffix="right"/> </mix> ! ! <policy label_suffix="left" record="left"/> ! <policy label_suffix="right" record="right"/> ! ! </config> This configuration defines two signals "left" and "right" that are mixed from the audio input of the matching <play> clients. In the example, each play session labeled as "left" is mixed into the "left" signal. Each <mix> node can host an arbitrary number of <play> nodes. The same <play> policy can appear at multiple <mix> nodes. A <policy> node assigns a signal to a record client. In the example, a record client labeled "left" is connected to the <mix> signal "left". The mixer allows for the cascading of <mix> nodes. For example, the following signal "lefty" is a mix of the two signals "left" and "right", weighted by respective volume attributes. ! <mix name="lefty"> ! <signal name="left" volume="0.7"/> ! <signal name="right" volume="0.3"/> ! </mix> [image mixed_waveforms] Example of the mixer output for a sine wave as the "left" signal (top), a signal mixed 70:30, a signal mixed 30:70, and a square wave as the "right" signal (bottom). The operation and configuration of the mixer is described in more detail by the accompanied README at _os/src/record_play_mixer/_. The inter-component interfaces are located at _os/include/play_session/_ and _os/include/record_session/_. The _gems/run/waveform_player.run_ script illustrates the integration of the mixer by using a waveform generator as multi-channel play client and an oscilloscope as record client. Current state and next steps ---------------------------- The new infrastructure is ready to be exercised by the synthetic example mentioned above as well as by the _audio_out.run_ and _audio_in.run_ scripts located at _repos/dde_bsd/run/_. The OpenBSD-based audio driver can be operated in either of two modes. By default, it is compatible to the old audio in/out interfaces. The new record/play mode can be enabled by setting the 'record_play="yes"' config attribute. Over the next release cycle, we will successively convert the other pieces of the audio stack, in particular the other drivers and the OSS VFS plugin, to the new record and play interfaces. Following this transition, the original audio in/out interfaces will be removed. Sculpt OS as remote test target for the Goa SDK ############################################### The run-stage generalization from [https://genode.org/documentation/release-notes/23.08#Run-stage_generalization - release 23.08], paved the way for the new run-target "sculpt" that allows using Sculpt OS as a remote test target for 'goa run'. Since Goa already placed all the required files for running a scenario into a _var/run_ directory, adding this target merely involved coming up with a solution for synchronizing the run directory with Sculpt OS and getting a hold of the log output. The implementation in Goa is accompanied by a _goa_testbed_ package that starts a remotely-controlled subsystem on Sculpt OS. It particularly hosts a _lighttpd_ and _tcp_terminal_ component. The former is used for run-directory synchronization based on HTTP PUT. The latter provides the log output of the test scenario via telnet. For more details, you may take a look at the corresponding [https://genodians.org/jschlatow/2024-01-29-goa-sculpt - blog post on genodians.org]. In order to integrate support for this mechanism into Sculpt OS, we supplemented the NIC router configuration with a _http_ and a _telnet_ domain. Each of these domains is intended to accommodate a single client. Ports 80 and 23 of the _uplink_ domain are then forwarded to the clients in the _http_ and _telnet_ domain respectively. This is complemented by the _goa_testbed_ preset added to the PC and PinePhone version of Sculpt OS that turns the system into a ready-to-use remote test target. You can see this feature in action in our [https://genodians.org/nfeske/2024-02-15-fosdem-aftermath - FOSDEM talks]. When implementing the Sculpt target in Goa, we also had to come up with a way to supply Goa with the IP address of the remote test target. Goa's modularity w.r.t. custom run stages motivated us to implement a generic mechanism for target-specific options. For this purpose, we added the config variable 'target_opt' that is defined as a Tcl array. The Sculpt target evaluates the array elements 'sculpt-server', 'sculpt-port-http' and 'sculpt-port-telnet'. We further augmented Goa's command-line parsing such that individual elements of the 'target_opt' as well as the 'version' config variables, which are both arrays, can be supplied as command-line arguments. The corresponding arguments follow the pattern '--target-opt-<option>' and '--version-<user>/<type>/<name>'. Base framework and OS-level infrastructure ########################################## TCP/IP stack based on DDE-Linux version 6.1.20 ============================================== Over the course of the previous four releases, we have gradually modernized the arsenal of Linux-based drivers to use our modern Linux device-driver environment based on Linux 6.x. The final piece of code standing in the way of the removal of our legacy DDE Linux approach has been Linux's TCP/IP stack. The stack was based on Linux version 4.4.3 and did not even take advantage of lx_kit supported features like cooperative scheduling. For this reason, it was about time to update the TCP/IP port while also adapting it to our [https://genode.org/documentation/release-notes/21.08#Linux-device-driver_environment_re-imagined - modern] DDE approach. Being in such an ancient state, this effort ended up being more of a re-write than an actual update. The IP stack is also one of the few DDE Linux components that is a shared library, as opposed to most drivers, which are executable binaries. This led to improvements of our lx_kit, for example, we had to replace static C++ constructors by automatically generated functions for kernel module-initialization calls because C++ constructors are supposed to be called by the binary and not during library initialization (Section [Linux-device-driver environment (DDE)]). Additionally, we took the opportunity of experimenting with a socket C-API with the ultimate goal to replace the VFS plugins for Linux (vfs_lxip) and lwIP (vfs_lwip) with a unified version, but this is an ongoing effort. Nevertheless, with the current release, the update of our Linux TCP/IP port is complete and, from a user perspective, the new version as well as the updated VFS plugin are drop-in replacements for version 4.4.3. The transition should be seamless. While porting the IP stack, we also investigated a long-standing issue regarding the memory consumption of the IP stack, which always seemed a little too high. We were able to identify the hash tables used for locating sockets as the main reason. These tables are configured for server loads per default (meaning > 1 million sockets), which Genode with one or few (VFS server) clients per IP stack does not default to. This enabled us to reduce the amount of hash table allocations during IP stack initialization, which leads to reduced memory demands (>10MB) of the IP stack. With the new IP stack in place and no legacy components remaining, we removed the DDE Linux port file (_dde_linux.port_) and the legacy lx_kit/lx_emul marking the update to the current DDE approach as complete. De-privileged tracing ===================== Genode got equipped with a light-weight event tracing facility in [https://genode.org/documentation/release-notes/13.08#Light-weight_event_tracing - version 13.08]. The underlying core service - appropriately named TRACE - used to be an outlier among core's services in that it provided a privileged interface with system-global reach. A trace client is assumed to play a privileged role and must be ultimately trusted. This is arguably fine for the typical use cases where event tracing is used in the lab. However, anticipating on-target debugging on Sculpt OS, the desire for on-target tracing by untrusted trace monitors casually running on Sculpt OS is anything but far-fetched. To allow for the secure use of untrusted trace monitors, the global reach of core's trace service is no longer satisfactory. The current release changes core's trace service to expose trace subjects only if their PD label matches up with the label of the trace monitor. Hence, by default, a trace monitor can only observe itself and its child components. Only if the trace monitor's parent rewrites the trace-session's label, the view of the trace monitor can become broader. For example, when rewriting the trace label to an empty string "", the trace monitor becomes able to observe the sibling components hosted in the same init instance as the trace monitor. Note that the trace-subject label as reported as subject info to a trace monitor is now given relative to the label of the trace session. To grant a trace session the special privilege of obtaining a global system view (including the kernel's trace subjects), the top-level init has to rewrite the session's label to an empty string. At core, this specific label "init -> " is handled as a special case that discharges the namespacing of trace subjects. In Sculpt OS, the user can now select one of three options when connecting a trace monitor to core's trace service. The "component" option restricts the tracing to the trace monitor itself, the "deployment" option exposes the entire runtime subsystem to the trace monitor, whereas the "system" option exposes the entire Sculpt system to the trace monitor. The latter two options require adequate trust in the trace monitor. Deferred unlinking of files in VFS RAM file systems =================================================== UNIX systems defer the physical deletion of a file until the last file descriptor referring to the file is closed. Since Genode's VFS does not (try to) implement this scheme, we encountered a few difficulties while porting 3rd-party software to Genode. In some situations, a parent process of a Unix-like subsystem may pass the content of an unlinked file to a forked child process. This can be observed when using the 'exec' command in Tcl scripts. Another example is the use of the 'tmpfile()' POSIX function. In the use cases we observed, the mechanism was merely used for _/tmp_ files, which are usually backed by a '<ram>' file system in Genode's VFS. Hence, to accommodate these programs, we changed the unlink operation of the ram fs to defer the destruction of a file until it is no longer referenced by any VFS handle. When unlinked, the file no longer appears in the directory. But it can still be opened and accessed. Improved API safety of MMIO accesses ==================================== The 'Register' respectively 'Mmio' APIs have become predominant in Genode's native drivers where the type-safe access to hardware registers has become a second nature. However, up until recently, one point of uncertainty remained: Since the 'Mmio' utility evaluated only the base address of a memory-mapped I/O range, all associated register definitions were assumed to be fully contained within the corresponding local memory mapping. An accidental violation of this assumption would remain undetected. The current release replaces this optimistic assumption by a combination of two mandatory upper-bounds checks. Each 'Mmio' instance is now qualified with a 'size_t' template parameter denoting the size of the memory-mapped I/O range in bytes. Each register definition within the 'Mmio' is statically checked against this upper bound at compile time. At runtime, the local memory mapping of the I/O range is checked against the statically defined 'Mmio::SIZE'. A violation is considered a non-recoverable driver bug, prompting an error message along with a 'Range_violation' exception. This change modifies the API. Existing driver code must be adapted in two respects. First, each 'Mmio' definition must be annotated with the expected size in bytes as template argument. Second, the 'Mmio' constructor requires a 'Byte_range_ptr' argument instead of a plain 'addr_t' value. Application-level VFS file watching =================================== The convenience API at _os/vfs.h_ provides utilities for using the VFS as a stand-alone library without depending on the libc. Among its utilities, there exists the so-called watch handler that can be used to monitor file modifications. As watch handlers were primarily used by VFS plugins and the C runtime, they used to operate in the context of low-level I/O signal handlers. Code executed in this context should generally not involve any global side effects that depend on I/O signals themselves (like synchronous file access). With the current release, the 'Watch_handler' becomes safe to use at application level where global side effects are anticipated. The former use case is now covered by the dedicated 'Io::Watch_handler'. Device drivers ############## Linux-device-driver environment (DDE) ===================================== ARMv6 compatibility ------------------- In the previous release, we updated our [https://genode.org/documentation/release-notes/23.11#USB_device_drivers_updated_to_Linux_6.1.20 - USB device drivers] to Linux 6.1.20 using 'virt_linux'. Drivers or protocol stacks based on 'virt_linux' do not access hardware directly. They either communicate through another instance - like the USB host controller for USB device drivers - with the hardware or do not require hardware at all (e.g., TCP/IP, WireGuard). The 'virt_linux' flavour is still CPU-architecture specific because it contains low-level assembly code. A limitation of Genode release 23.11 was that there is no support for ARMv6 in 'virt_linux'. As devices based on ARMv6 can still be found in the wild (e.g., Raspberry Pi Zero), the current release supplements support for ARMv6 to 'virt_linux', the USB device drivers, and the TCP/IP stack. For this to work, we had to separate code shared by ARMv6 and ARMv7 platforms. In many places, there would be a directory like _spec/arm_, which would contain build rules or code for both architectures. ARMv6 and ARMv7 have many things in common - until they don't. With the current release, we have split these folders into _arm_v6_ and _arm_v7_ respectively and while we were at it renamed _arm_64_ into _arm_v8_ for consistency. With this approach, it became possible to introduce ARMv6 and ARMv7 specific kernel configurations to 'virt_linux', and thus, enable support for drivers/protocol stacks for both architectures. Initcall handling without relying on global constructors -------------------------------------------------------- When porting Linux drivers, a lot of code is placed into modules. Modules always have a magic module-function call (e.g., 'module_init'), which registers a function for the initialization of the module and is executed during kernel startup prior device probing. DDE Linux mapped 'module_init' indirectly to a macro that generated a function as a static constructor (ctor), which in turn registered the required module function (Note: This is simplified because there is also an order that must be preserved). This solution required all ported components to call 'exec_static_constructors' in order to trigger the registration of module-init calls before executing any other Linux kernel code, but not before the 'Lx_kit' initialization because the init-call functions had to be registered in advance. This scheme led to hen-and-egg problems in our TCP/IP stack (Section [TCP/IP stack based on DDE-Linux version 6.1.20]) and our WiFi driver port because they are shared libraries where static constructors must be called at a later stage. In order to avoid these kinds of problems, we changed the module-init approach by replacing the macro-generated functions with global-function pointers with a well known prefix. These pointers are collected by the DDE-Linux-build system using ELF reading tools (i.e., 'nm') after the compile step and are placed into a function ('lx_emul_register_initcalls') which is called during 'Lx_kit' startup. This way, no changes to existing drivers are necessary, and the static constructor problem disappeared for the shared library cases. Note: Any ported driver still using 'exec_static_constructors' can remove the call after checking if there are no static constructors from other C++ objects present. Suspend/resume awareness of GPU, AHCI, and NVMe drivers ======================================================= As a further step towards general ACPI suspend/resume support, our custom-developed drivers for Intel GPU, NVME, and AHCI got re-worked to cooperate with the feature. Before the final suspend, the drivers can now be notified to stop processing further client data and to shut down the devices used by closing the 'Platform::Device'. This prompts the platform driver to power-off the corresponding PCI device. However, DMA buffers containing all the client data are kept in memory and are not de-allocated. This means that the client sessions for GPU and 'Block_session' can stay intact (for ACPI S3 - suspend to memory) and don't require a restart of the users of GPU, NVME, and AHCI on resume. On resume, after the kernel is up again, the drivers need to get notified to re-acquire the PCI device from the platform driver. The platform driver will power-on the re-acquired devices and the GPU/NVME/AHCI drivers will set up the device resources, e.g. MMIO and IRQ, and then re-initialize the devices. The drivers will finally restart processing session requests. This way the clients will just continue to operate as though nothing had happened. The test scenario for suspend/resume can be test-driven by using _run/acpi_suspend_, which contains a periodic suspend-resume cycle for developing purposes. Dynamic aperture handling for high resolution framebuffers ========================================================== We extended the Intel GPU driver with a configuration option to specify the amount of the graphics aperture provided to the ported Intel display driver. Beforehand it was a fixed amount (64M), which may not suffice for all use-cases. The aperture is a shared resource, which must be used for various GPU-related internal data structures and is used from CPU side for access to the framebuffers by the display driver. When the display driver sets up several framebuffers with high resolutions, the fixed amount may be too small. The snippet below shows the new configuration option and the default value: ! <start name="intel_gpu_drv" ...> ! <resource name="RAM" .../> ! <provides> ! <service name="Gpu"/> ! <service name="Platform"/> ! </provides> ! <config max_framebuffer_memory="64M"> ! ... Improved human-interface device handling ======================================== In preparation of the _support for I2C-based HID (touchpad) devices_ [https://genode.org/about/road-map#February_-_Release_24.02 - road-map item], we dusted off several aspects of our input-event handling from the drivers over the event API to the event-filter component. At the heart of the improvements, we developed a broad understanding of the specifics of the different motion-event device types that are widely in use. First, there are mice and touchpads, which generate relative-motion events that are translated by the GUI stack to movements of the GUI pointer. Then, we have three kinds of absolute-motion devices: pointers (e.g., Qemu usb-tablet or IP-KVM device like [https://pikvm.org/ - PiKVM]), touchscreens, and graphics-tablet tools (e.g., stylus). These devices require translation of device-specific absolute coordinates to screen coordinates. On the driver side, we rewrote our custom *evdev* driver that interfaces with all current and future ported Linux input drivers. Now, evdev covers all peculiarities of the different device types, for example, touch devices that report up to 16 event slots (resp. fingers), and reports them via Genode Event sessions. Also, we implemented minimal "gesture" support for simple tap-to-click for touchpads that could be improved in the future, e.g., by two-finger-scrolling. Based on the rewrite, we could easily enable support for the Magic Trackpad in usb_hid_drv. The event filter was extended by a filter node to transform touch and absolute-motion event coordinates by a sequence of primitives expressed in sub-nodes, namely translation (move), scaling, rotation, and flipping. For example, the scaling of 32767x32767 touch coordinates to a FullHD screen is configured like follows. All primitives are documented in the event-filter README file. ! <transform> ! <input name="usb"/> ! <scale x="0.0586" y="0.0330"/> ! </transform> Additionally, the event filter now supports to optionally log motion and touch events beside keys and buttons. ! <log motion="true"> <input name="usb"/> </log> Unfortunately, the developments outlined above delayed the actual integration of the prospected I2C HID support to a later release. Multi-client use of Vivante GPU (i.MX8) ======================================= In this release, we brought our port of the etnaviv driver, which was still limited to one client only, up to speed. It now joins the other GPU drivers in providing multi-client support. Back in release [https://genode.org/documentation/release-notes/21.11#Vivante_GPUs__i.MX8_ - 21.11], we added support for the Vivante GC7000L GPU featured in the i.MX8MQ SoC to Genode via a port of the etnaviv Linux and Mesa3D driver. As a blueprint, it served us well when enabling another GPU for a different ARMv8 SoC, namely the Mali GPU in the PinePhone. The etnaviv port itself, however, never left its initial state and was able to cater to one client only. For this reason it was co-located and deployed in tandem with the client requiring its service. This factor somewhat restricted its usefulness in Sculpt when used in a desktop-like capacity on, e.g., the MNT Reform. The current release lifts this limitation and enables the driver to accommodate multiple clients at the same time. Libraries and applications ########################## VirtualBox ========== As a debugging aid, we enabled the reporting of Windows Blue Screen of Death (BSOD) reasons in our VirtualBox port. To enable the output, the new release adds a default of '+dbgf+gim' to the 'VBOX_LOG' environment variable. With VirtualBox Guest Additions installed in the Windows guest, after a "Guest indicates a fatal condition!", the reason for the blue screen will be printed to the log. Seoul VMM ========= Several improvements got added since the previous Genode release, which showed up during daily use of a Genode developer VM. On the one hand, the exported guest-cursor shape was a bit offset from its actual position. Besides the guest shape, small hot_x, hot_y shifts are exported, which are now considered in order to position the mouse cursor shape more accurately. Additionally, the processing of alt-gr and <>| keys on German keyboard layouts got enabled. Finally, the AHCI model and the bindings to the Genode block session got reworked. Up to now, the AHCI model could not cope with delaying a block request in case the block session was saturated. Instead of making temporary copies, as done before, the AHCI model now supports keeping guest requests in guest memory when necessary and resumes block operations as soon as the block session is able to process more requests. Lighttpd web server version 1.4.73 ================================== We updated our port of the [https://www.lighttpd.net - lighttpd] HTTP server and at the same time also extended its feature-set by enabling the WebDAV module. Rather than being used as a general purpose HTTP server that comes with all bells and whistles, it powers our [https://genodians.org - Genodians] appliance in static fashion and with WebDAV in place is now also the foundation for the goa testbed introduced in Section [Sculpt OS as remote test target for the Goa SDK]. Jitterentropy version 3.4.1 =========================== Back in 2014, we ported the [https://www.chronox.de/jent/index.html - jitterentropy library] as a basic component-local entropy source for seeding pseudo random-number generators like [https://prng.di.unimi.it/ - Xoroshiro] or [https://www.pcg-random.org/ - PCG]. As the last port update dates back years, we brought the most recent version 3.4.1 of jitterentropy to Genode. The new library is API-compatible to the old version and can be integrated as usual via the '<jitterentropy>' plugin into your VFS configuration. Build system and tools ###################### Goa SDK ======= In addition to the support for using Sculpt as test target for Goa (Section [Sculpt OS as remote test target for the Goa SDK]), the latter underwent quite a few usability adjustments. As announced in [https://genode.org/documentation/release-notes/23.08#Support_of_index_projects - release 23.08], Goa has been enabled to export and publish a personal depot index. The depot index lists the depot user's packages in a nested structure of '<index>' nodes. The initial support for index projects, however, was restricted to two levels of '<index>' nodes. We eliminated this restriction in order to clear the path for large depot indexes with hierarchical structure. When using Goa to export and publish a depot index, one always had to provide the '--depot-overwrite' switch in order to overwrite the current depot index. Goa also propagated this switch to any sub-project that got exported along with the depot index. In practice, however, an index project will typically be exported and published when development on all sub-projects has finished, hence there is no need for re-exporting already exported sub-projects. We therefore added the '--depot-retain' switch in order to express the intent to not overwrite any depot content. Instead of propagating the '--depot-overwrite' switch, Goa now uses the '--depot-retain' switch when it automatically exports sub-projects. Along with the support for index projects, Goa had been equipped with the ability to lookup version information from other project directories. By default, Goa uses the current working directory as a starting point for the lookup of projects and their versions. The practical use of this was still limited, though, since it required using the '-C' argument to execute Goa from a different directory than the project directory. We thus introduced the 'search_dir' config variable that allows defining the directory from which Goa starts searching for depended on projects. When porting CMake-based projects with Goa, we often needed to patch the _CMakeLists.txt_ or add quirks to Goa in order to disarm CMake's 'find_library' command. Instead of resorting to those ad-hoc solutions, we decided to add support for _FindXXX.cmake_ files in api archives. Any api archive mentioned in the _used_apis_ file is now added to the 'CMAKE_MODULE_PATH' so that CMake is able to correctly identify the presence of depended on libraries via the _FindXXX.cmake_ files. An example is found in the Goa repository at _examples/cmake_sdl2_. In addition to the aforementioned changes, we added a couple of minor tweaks: * We added the sub-commands 'goa help index' and 'goa help runtime' to document the structure of _index_ and _runtime_ files. * The sub-command 'goa bump-version' now creates a _version_ file if none exists. Convenient parsing of backtraces ================================ The new _tool/backtrace_ parses the copied and pasted shared library info of a component (generated with <config ld_verbose="yes"/>) and the log output of the 'Genode::backtrace()' function and prints the corresponding source locations in a convenient way.