Release notes for the Genode OS Framework 25.02

Genode 25.02 delivers a healthy mix of features, optimizations, and hardware-compatibility improvements.

The prime feature is the continuation of the multi-monitor topic of the previous release, covering multi-monitor window management and going as far as seamlessly integrating multi-monitor virtual machines (Section Multi-monitor window management and virtual machines). The second and long anticipated feature is the Chromium engine version 112 in combination with Qt 6.6.2, which brings our port of the Falkon web browser on par with the modern web (Section Qt, WebEngine, and Falkon browser). On the account of exploratory activities, we are happy to report that Qemu can now be used directly on Genode (Section Qemu on Genode).

This year's road map emphasizes rigidity, clarity, and performance. So it is no surprise that the new version delivers on that front. We have cut down graphics-related performance bottlenecks by factor 3 by leveraging SIMD (Section SIMD optimizations), made the page-fault handling of our custom base-hw microkernel more efficient, and lifted scalability limitations when using the seL4 and Fiasco.OC kernels (Section Platforms).

Regarding hardware support, the kernel-agnostic IOMMU support got complemented with IRQ protection on x86, and the Genode-based Sculpt OS has become compatible with the latest Intel Meteor Lake Framework laptop as well as embedded F&S MX8MP armStone boards.

Multi-monitor window management and virtual machines

With version 24.10, Sculpt OS became usable for mirrored and panoramic multi-monitor setups. In a panoramic setup, each display shows a portion of a larger panorama maintained by the nitpicker GUI server. So far, only the administrative user interface had been multi-monitor-aware. It is always presented on the display that hosts the mouse pointer to ensure that the entirety of the user interface is reachable at all times. All other parts of the GUI stack, however, interpreted the entire panorama as one large display spanning all monitors.

The current release extends Genode's multi-monitor awareness to the window manager and its companion components, thereby addressing the interplay between virtual desktops and physical displays, preserving the reachability of all applications whenever a monitor is unplugged, and improving the ergonomics of interactive window manipulations.

GUI stack

The GUI stack comprises the following components.

At the bottom, one or more display drivers access the physical monitors attached to the machine. For each monitor, the driver maintains a distinct physical framebuffer and creates a capture session at the GUI server. From the perspective of the GUI server, a display driver appears as a GUI capturing client, not unlike a screen recorder. The GUI server maintains a single panorama, which is a 2D coordinate system where GUI applications are placed. Its configuration defines which part of the panorama gets exposed to which capture client. In the example, the eDP capture client obtains the left part whereas the HDMI capture client obtains the right part.

The window manager (wm) uses the nitpicker GUI server as client and acts as a GUI server itself, providing the same interface as nitpicker. Sitting in-between the nitpicker GUI server and the application, it transparently supplements the notions of windows, virtual desktops, and the keyboard focus. Among the window-manager clients, two components stand out by having special roles. The window layouter defines which application is presented at what location in the panorama by generating a window layout. The window layout is produced according to user configurable rules, which are updated by interactive layout changes like moving a window. The decorator, in turn, paints window decorations according to this window layout. Note that neither the layouter nor the decorator are able to observe information displayed by the applications or any user input directed to applications.

The window layouter introduces the abstraction of virtual desktops, named screens for brevity. Each screen can be assigned to a part of the panorama. If two screens are assigned to the same part, only the top-most screen is displayed. In the example, screens 1 to 3 are assigned to the part captured by the eDP monitor whereas screens 4 to 6 are assigned to the part captured by the HDMI monitor.

A regular GUI application connected to the window manager only observes its corresponding display as its virtual panorama. A multi-window application maintains one GUI session per window. So from the window-manager's perspective, each window appears as a separate GUI client.

Screen-to-display assignment

The layouter rules can host any number of display declarations as follows.

 <display name="primary"/>

Optional attributes xpos, ypos, width, and height can be specified to assign a specific rectangle of the panorama to the display. Otherwise, the window layouter applies the following policy. The captured rectangles present in the panorama are assigned to displays in left to right order. This gives the opportunity to assign the notion of a "primary" or "secondary" display to different parts of the panorama by the mere order of <display> nodes. If more displays are declared than present, all unassigned displays will refer to the left-most captured rectangle of the panorama.

To get more precise control over the assignment of captured areas to displays, a display node can host any number of <capture> sub nodes that are matched against the captured areas present within the panorama. The panorama areas are named after the labels of capture clients (i.e., display drivers) connected to the nitpicker GUI server. The matching can be expressed via the attributes label, label_prefix, and label_suffix. The first match applies. E.g., the following configuration may be useful for a laptop that is sometimes connected to an HDMI display at work or a Display-Port display at home.

 <display name="primary">
   <capture label_suffix="HDMI-1"/>
   <capture label_suffix="DP-2"/>
   <capture label_suffix="eDP-1"/>
 </display>
 <display name="secondary">
   <capture label_suffix="eDP-1"/>
 </display>

When neither the HDMI-1 display nor the DP-2 display is present, the laptop's internal eDP display is used as both primary and secondary display. Once an external display is connected, the external display acts as primary display while the laptop's internal display takes the role of the secondary display.

Once declared, the display names can be specified as display attribute to <screen> nodes, thereby assigning virtual desktops to displays. Screens referring to the same portion of the panorama are organized as a stack where only the top-most screen is visible at a time. As each display has its own distinct stack of screens, one screen cannot be visible at multiple displays. To mirror the same content on multiple displays, it is best to leverage the <merge> feature of the display driver. Should a <screen> lack a valid display attribute, it spans the entire panorama.

Improved focus switching and free-arrangeable layouts

The switching within the focus history (Super-Tab) is now restricted to windows that are located at visible screens. This avoids the need to tab through invisible windows, which can be confusing when using windows scattered across several virtual desktops.

Furthermore, the focus is now automatically changed to the most recently focused visible window whenever the currently focused window becomes invisible. This happens when switching between virtual desktops. This behavior hopefully also fits well with focus handling of temporary windows. When a temporary window appears, it needs to be focused manually (to prevent focus stealing). But once the temporary window disappears, the focus returns to the previously focused window.

For interactively moving or resizing a window, the user needs a good aim to grab the corresponding window handles as presented by the decorator. We have now supplemented the ability to click anywhere within a window while the wm-modifier key (i.e., Super) is held. Depending on the position within the window, the click is interpreted as click on the title (when clicking at inner 50% of the window, or as a click on the border (when clicking at an area nearby the window boundary).

Up until now, the warping of a window to another screen required a manual modification of the layouter rules, which is arguably not perfectly user friendly. Now, for screens visible side by side in a multi-monitor setup, a window can be moved from one screen to another by dragging the window title. When using screens as virtual desktops on one display, a window can be moved to another screen by switching the screen (by pressing a key matching a desired screen) while the window is dragged with the mouse. So the user can drag the window between virtual desktops.

As an additional convenience, the currently focused window can now be taken to another screen by pressing the wm-modifier key together with Shift and the screen number.

Versioned layouter rules and new defaults

To accommodate the multi-monitor window management, we had to extend the window-layouter rules. By renaming the rules file to a version number reflecting the date of change (24.12), we prevent the loss of window-layout state when switching back and forth between different versions of the window layouter.

The default rules now contain the definitions of three displays ("primary", "secondary", and "ternary") and map three screens to each display.

Multi-monitor virtual machines

A notable client of the window manager in the multi-monitor setting is VirtualBox, a prime example for virtual-machine monitors. For a seamless user experience, real displays must be integrated as virtual monitors inside the VM that can be dynamically enabled or disabled. The virtual monitors then reflect the physical display configuration and can, thus, be configured in the guest operating system as a virtual panorama.

For that purpose, we extended VirtualBox by a two-stage monitor configuration. First, the <Display> node in the .vbox configuration file defines the maximum number of potentially connected virtual monitors by the monitorCount attribute.

<Display VRAMSize="64" monitorCount="2"/>

Each enabled VirtualBox monitor requests a dedicated GUI session, which is equivalent to a window on screen as described above. Now, the enablement and labeling of these sessions is done via <monitor> nodes in the VirtualBox runtime configuration as follows where up to monitorCount monitors are supported.

<monitor label="right"/>
<monitor label="left"/>

The labels can be used in window-manager rules to configure and place the corresponding window inside the panorama. The order of the nodes directly controls the connection order at the virtual graphics card, which is important for the in-guest configuration of the virtual panorama. Note that, at least one monitor configuration node is required as otherwise no virtual monitor will be enabled. This is in contrast to prior versions, which always enabled one monitor.

Qemu on Genode

Qemu is an all-purpose open-source tool for cross-architecture emulation for whole operating systems. Its merits for efficient and rapid developments are unmatched for many system developers. It thereby plays a very important role in Genode development.

We have longed for using Qemu natively on Genode for quite a time now - as documented by this GitHub issue, which dates back to 2012. Actually, in 2019 there was already an attempt (see the issue) to get Qemu up and running, which - well - succeeded to the degree that it compiled and linked. At that time the build system of Qemu was way too complex to be used directly by the Genode framework and hand-made solutions were common. Usually, once the initial rush of motivation drops, such on-off efforts tend to become neglected, which happened to happen also for the 2019 Qemu attempt. So the approach was condemned to fail in the long run.

Since then, the Goa tool entered the picture and evolved over the years to the point where it became tempting to give a Qemu port a second try. The approach of Goa to reuse the unmodified build infrastructure of the 3rd-party software as closely as possible induced hope. Hence, over the last year, we have worked on bringing Qemu - with the help of Goa - to Genode and we are happy to announce a state that is able to run Qemu 9.0.1 on x86_64 for emulating ARM target architectures, e.g. qemu-system-aarch64 and qemu-system-arm.

The Goa sources of the port are available via alex-ab's Goa repository. Additionally, ready-to-use packages for Sculpt OS 24.10 are available. After downloading the packages via alex-ab's Sculpt index and deploying them, initial configuration files named config.qemu.aarch64 or config.qemu.arm will be imported into the selected file system. Those files can then be adjusted for the desired board to emulate, e.g:

 ...
 <arg value="qemu-system-aarch64"/>
 <arg value="-M"/>         <arg value="raspi3b"/>
 <arg value="-m"/>         <arg value="1024"/>
 <arg value="-nographic"/>
 <arg value="-serial"/>    <arg value="null"/>
 <arg value="-serial"/>    <arg value="mon:stdio"/>
 <arg value="-kernel"/>    <arg value="/image_raspi3b"/>
 ...

The example shows the familiar Qemu configuration options in Genode's XML configuration style. In the example above, a Raspberry PI 3b target has been set up that expects a kernel image named image_raspi3b to be located next to the configuration file. After adjusting the configuration file, the component merely needs to be restarted and Qemu will boot with the new configuration.

The current port is still work in progress. Further potential directions are the support of qemu-system-x86_64 and support for Genode's VM session interface to leverage hardware-assisted virtualization, and thereby complementing the existing Seoul VMM and the VirtualBox VMMs on x86 with a further powerful option.

Qt, WebEngine, and Falkon browser

A big motivation for the ongoing effort to update our Qt port from Qt5 to Qt6 was the prospect of an updated Chromium web engine for the Falkon web browser as more and more websites stopped working correctly with Chromium version 83 of Qt 5.15.2. This release updates our Falkon port to version 24.01.75, which in addition to the previous Qt 5.15.2 port can be built with the freshly added Qt 6.6.2 web engine port based on Chromium version 112.

Not all features of the previous Qt5-based Falkon are working yet, for example support for video capturing from a webcam is still missing, but other multimedia keatures like playing of YouTube videos are supported already.

Experimental Qt6 Falkon Sculpt packages are available in the cproc depot, but require a Sculpt version built from the current Genode release. They will also be made available for the upcoming official Sculpt release.

Aside from the new Qt6 web engine and Falkon ports, we also split the previous Qt6 port into smaller ports for the individual Qt modules to avoid having to download and store the huge QtWebEngine code base when it is not needed.

Base framework and OS-level infrastructure

Init configuration improvements

Simplified RAM assignments

In init's configuration, the assignment of RAM to a component is expressed as follows:

 <start name="report_rom">
   ...
   <resource name="RAM" quantum="2M"/>
   ...
 </start>

We have now introduced a new ram attribute as a concise alternative.

 <start name="report_rom" ram="2M">
   ...
 </start>

This change is complemented with the ability of defining a global default RAM quota following the existing pattern of the default caps definition, e.g., the following <default> node alleviates the need to repeatedly state reasonable ram and caps values in each single start node.

 <default caps="100" ram="1M"/>

Partial session-label rewriting

When routing a session request, a route can be selected by using a label (or a label suffix or a label prefix) as key. In the target node (<parent/> or <child name="..."/>), it is possible to replace the label by another one. For example, the following routing rule matches a ROM session labeled "config". If the route is taken, the session is directed to the config_fs_rom server and the label is rewritten to "managed/runtime". So the server will hand out this file as ROM module, which then appears as "config" at the client.

 <route>
   ...
   <service name="ROM" label="config">
     <child name="config_fs_rom" label="managed/runtime"/> </service>
   ...
 </route>

In hierarchic scenarios (e.g., nested instances of init), labels assume a form like "runtime -> system_shell -> terminal -> config". The client's intent (in this case, the client wants to obtain "config") is successively watermarked by the components in the chain of authority involved in the session creation. In the example, the terminal's session request traverses the system-shell init as well as the runtime init before reaching the server.

In short, the label encodes two things: the expression of the client's intent (naming a server-provided resource like ROM module), and an unforgeable (by the client) representation of the client's identity as observed by the server. The former is the last part of the label whereas the latter are all the leading parts.

Init's label-rewriting mechanism is a useful tool of abstraction, which allows for grouping clients to roles. However, as the label can only be rewritten as a whole, the rewriting rule needs to know both the client's identity and the client's intent. Should the client's intent vary (e.g., a client requesting a variety of ROM modules), a dedicated rewriting rule is needed for each case. By introducing the following new attributes for the selective rewriting of only the identity or the resource part of the label, such policies become much easier to express.

identity="rw": replaces the identity part of the label by "rw" while keeping the resource part. So the client's identity can be replaced by a role while keeping the client's intent intact.
resource="/bin/": replaces the client's intent while retaining the client's identity. Here, a client's request for a file-system session becomes hardwired to one directory of the server.
prepend_resource="/usr/local": prepends the resource part of the label with a given prefix. The example restricts the client-provided path to the bounds of the server's /usr/local/ directory, as a substitute for the traditional chroot component.

Enriched file-system session-label convention

Genode 25.02 changes the way of how a client-selected subdirectory is communicated to the file-system server at session-creation time. The former opaque session argument is now passed as last label element, which allows for the flexible tweaking of this argument by init's session-routing and label-rewriting mechanisms. In particular, it alleviates the need for creating chroot component instances.

This change requires the following four adaptations at the configuration level:

Each file-system session request must now carry a path starting with / as last session argument. Hence, <fs> nodes of the VFS that feature a label attribute must extend the attribute value with " -> /". For <fs> nodes with no label attribute, "/" is used as last label argument by default.
For matching session-routing rules at init's configuration, the matching of full labels must be replaced by label_prefix matches, excluding the last (path) argument.
Wherever a label of a file-system session is rewritten by using init's label attribute in a <parent> or <child> target node, the new attribute identity should be used instead. This replaces the identity part of the label while preserving the client's directory argument.
Analogously to the matching of session-routing rules, server-side policy-selection rules that formerly matched a concrete label must be changed to match a label_prefix instead.

As a good practice, label_prefix values should end with " ->" if possible, which clearly delimits the identity part of the label used by the matching.

SIMD optimizations

With screen resolutions growing, the proliferation of multi-monitor setups, and in anticipation of screen-rotation support later this year, our existing pixel-shovelling routines show their limitations. This prompted us to investigate the use of SIMD (single instruction multiple data) for such purpose, leveraging ARM Neon on the 64-bit ARM architecture and SSE4 on the 64-bit x86 architecture.

We have put our attention on two well known bottlenecks, namely the back-to-front blitting performed by display drivers and alpha blending performed by the nitpicker GUI server. The existing blit library has been extended by two new interfaces Blit::back2front and Blit::blend_xrgb_a accommodating these use cases. With the planned support for screen rotation in the back of our heads, the back2front implementation supports the rotation by 0, 90, 180, and 270 degrees as well as screen flipping.

Our effort spent on the SIMD optimizations paid off. The new versions improve the performance roughly by factor 3 compared to our original routines. Non-SIMD implementations of the same interfaces are available as fallbacks, which are employed on 32-bit architectures and RISC-V.

Device drivers

User-space IOMMU support for IRQ remapping

While adding kernel-agnostic DMA protection in Genode 23.11, we intentionally left IRQ protection out of scope. This release completes the kernel-agnostic IOMMU enablement on Intel platforms by adding IRQ-remapping support to the platform driver.

Since the platform driver already controls the MSI/MSI-X enablement for PCI devices, setting up the corresponding remapping tables was rather straightforward. Integrating remapping support for legacy interrupts, however, was a bit more involved. It required us to also add support for the I/O APIC (Advanced Programmable Interrupt Controller) to the platform driver. Similar to how the DMA Remapping Hardware Unit Definitions (DRHDs) are reflected in the acpi report generated by the ACPI driver and added to the devices report by our PCI decode component, the available I/O APICs are now also part of the devices report. With the added information, the platform driver is able to take over control of the interrupt controller and set up IRQ remapping unless the kernel already enabled IRQ remapping. Since the NOVA kernel already implements IRQ remapping, the platform driver's I/O APIC and IRQ-remapping logic is only effective on our base-hw kernel.

Note that as a prerequisite for handling IRQ remapping tables, we also needed to switch from using the register-based invalidation interface to the queued invalidation interface, which is the new default (if supported by the platform).

Sculpt-OS compatibility with F&S i.MX 8MP armStone

During the past six months, a lot of effort was spent to support additional NXP i.MX 8M Plus centered devices, like the Compulab IOT Gateway and the MNT Pocket Reform. With the current release, we extend the range of devices capable to run Sculpt OS by another board featuring this SoC, namely the armStone board from F&S Embedded.

As it is based on the same SoC, we were able to reuse most drivers for the platform like USB, MMC, or Ethernet. But to enable the more complex and board specific conglomerate of the display engine and differing connectors (HDMI instead of MIPI-DSI), we ported an alternative framebuffer driver from the vendor's Linux kernel fork to Genode.

With most peripheral drivers in place, we can now provide an instance of Sculpt OS running on top of the armStone board. To facilitate the build of an SD-card image, you can extend the RUN_OPT variable by:

 RUN_OPT += --include image/armstone_sdcard

This will automatically create an SD-card image whenever executing a run-script for the armStone board, e.g.:

 make run/sculpt_image BOARD=imx8mp_armstone

As the resulting SD-card image is not bootable directly - since the board relies on booting from eMMC - a second-stage loadable u-boot (with image-size constraints lifted) is readily included in the image.

USB

We addressed a shortcoming when selecting USB endpoints where only the interface number was considered in the selection process and the alternate settings number was ignored. Thereby the order, in which the interface descriptors were iterated, was accidentally determining the endpoint addresses that were communicated to the client, i.e., the USB device driver.

In case of mass-storage devices, like external SSDs, the usb_block driver tried to operate the device with the endpoint addresses belonging to the USB-Attached-SCSI (UAS) alternate setting rather than the bulk-only interface it supports.

With the fix that includes the alternate setting number in the selection process in place, the order is now of no consequence and the affected devices are working.

Audio

In order to improve user experience, especially with regard to video conferencing, we extended our OpenBSD based audio driver with an option to customize microphone selection. The <config> node of the audio driver now supports a mic_priority attribute. Supported values are "internal" and "external" (default). In case two microphones are present, e.g., a headset and an internal microphone on a notebook, a value of "internal" will enable the speakers of the headset and the microphone of the notebook whereas "external" will enable the microphone of the headset.

Platforms

Execution on bare hardware (base-hw)

Genode's custom kernel supports the notion of IPC-helping since the very beginning. This concept means that one thread calling another one via an Inter-Process-Communication (IPC) message will lend its own scheduling-abilities to the target thread. As the caller will block until it receives a response, this is a nice property to pass its time to the target side, which acts on behalf of the caller anyway. This nice concept was originally inspired by the NOVA kernel. However, in contrast to NOVA and most L4-like microkernels, the base-hw kernel does not use the IPC mechanism to forward page-faults to the pager thread that should resolve it. Thereby, all scheduling parameters, like priorities and CPU quanta that we can distribute in the system, are valid across component boundaries when using IPC, except for page-faults. But this can lead to unwanted interferences in between components of different priority bands that depend on the same pager thread. Therefore, we have generalized the notion of helping in our custom kernel to lend a thread's scheduling properties not only when doing IPC, but also when a page-fault occurs. Moreover, there is not only one global pager thread available anymore, but one pager thread per CPU.

To aid debugging during development of the base system, e.g., when adding new features or new platforms to the kernel, we have added additional detection and diagnostics about the hardware state should a page fault occur in unexpected conditions.

In order to support modern x86 hardware that doesn't feature a legacy programmable interval timer (PIT), we have consolidated the calibration of the time stamp counter (TSC) and local APIC to use the ACPI timer during bootstrap and provide the base-hw kernel with these calibration values as part of the boot information.

NOVA microhypervisor

With this release we added support to detect and parse x2APIC entries of the ACPI MADT tables, which contain information to locate and configure all CPUs during initialization of the NOVA kernel. Even though the x2APIC feature is required to support more than 256 CPUs, our actual motivation was a new Intel Meteor Lake based Framework notebook with 22 CPU cores. For this specific notebook, however, no MADT entries for local APIC entries were available, just the x2APIC entries. We used this circumstance to synchronize and harmonize the local APIC implementation of the NOVA upstream development with the NOVA version as used by Genode.

Lifted limitations on Fiasco.OC and seL4

During preparation of the Celebrating kernel diversity with Genode talk at FOSDEM 2025, the Fiasco.OC and seL4 based platforms received several improvements in order to demo their principal working states with Sculpt OS.

The base-foc version has become fit to boot on UEFI-based platforms by extending the core component to look up the initial ACPI RSDP information. Additionally, the base-foc capability-selector management in Genode got extended to support more capability selectors.

The base-sel4 platform received support to set up and use MSI interrupts for all devices and associated drivers, which improved the success rate of Sculpt OS noticeable on modern notebooks.

Finally, all modern kernels, namely NOVA, HW, Fiasco.OC, and seL4 are now using the pre-bootloader feature of bender to enable the Intel HWP feature during boot time consistently.

Build system and tools

Goa SDK

While working on several ports of 3rd-party software using the Goa SDK, we further tweaked its support of commodity build systems. This includes the propagation of shared-library linker flags and the execution of make install in autoconf-based and make-based projects. Moreover, Goa used to symlink the complete content from a project's src/ directory into the build directory. As this could create ping-pong effects with generated files, Goa now leaves generated files untouched (unless provided with the --rebuild flag).

Autoconf-based projects are now pointed to the used API archives for looking up pkg-config files. This prevents pkg-config from accidentally pulling library information from the host system and instead only takes this information from *.pc files in the referenced depot archives.

Furthermore, we updated the built-in depot archive versions to Sculpt 24.10.3.

Compilation changes

During the work on ARM Neon and Intel SSE4 in the context of the SIMD optimizations mentioned in Section SIMD optimizations, we encountered two limitations of our tool chain's default behavior:

First, even though Genode does not depend on the host system's C library (a few hybrid Genode/Linux components notwithstanding), the tool chain defines __STDC_HOSTED__ by default. This becomes a problem when using the ARM-Neon compiler intrinsics, which rely on the compiler's stdint.h, which in turn expects the presence of a C library whenever __STDC_HOSTED__ is set. To dispel this wrong expectation, we explicitly specify the -ffreestanding compiler argument by default now. In rare cases of a hybrid Genode/Linux components where this default is unwanted, this default can be overridden by setting CC_OPT_FREESTANDING to an empty value in the target's build-description file.

Second, the tool chain does not allow for the use of SSE4 compiler intrinsics on x86 by default. Instead of merely enabling SSE4 via the -msse4 compiler argument, we decided to globally switch to the -march=x86-64-v2 profile to denote the processor generation with all its features as common baseline. The profile corresponds to Intel Core processors of the year 2010 or newer, which still comprises our precious X201 notebooks with Intel Arrandale CPUs.

Streamlined handling of run-script preconditions

Not all run scripts are compatible with all kernels, boards, architectures, or circumstances. Usually, such constraints had been expressed by statements like this:

 if {![have_board pc]} {
   puts stderr "only supported on PC hardware"
   exit 0
 }

Over the years and with the number of run scripts growing, those preconditions have become complex and many. Moreover, run scripts backing out because of an unsatisfied precondition are not easy to distinguish from successful run scripts when executed in an automated fashion. Thanks to the welcome initiative of Roman Iten of Gapfruit, the precondition checks for executing run scripts have now become largely streamlined and much simpler.

The run tool has been extended by an assert function that is dedicated for expressing the preconditions of a run script. So the above example becomes:

 assert {[have_board pc]}

Note that the message can be dropped because any unsatisfied precondition is conveniently printed in the log. However, a more instructive message can be specified as an optional second argument.

To make this pattern as ergonomic and natural as possible, the naming of the run tool's various checking functions has been unified and slightly extended. The former get_cmd_switch and get_cmd_arg functions are now named have_cmd_switch and cmd_arg. A new have_recipe function returns true whenever the specified depot recipe is present. This way, the compatibility of a run script with any board where a drivers_interactive package is defined can be expressed in a much more concise way compared to the former enumeration of supported boards:

 assert {[have_recipe pkg/[drivers_interactive_pkg]]}

The change of the run tool is accompanied by an improvement of Genode's autopilot tool that now distinguishes unsatisfied run scripts from successfully executed run scripts.

Thanks to Roman for this careful, tasteful, and comprehensive contribution!

Meshcmd as alternative AMT tool

We use Intel Active Management Technology (AMT) on diverse native test hardware to forward serial output over network (SOL) to developer machines and to power-on, reset, and power-off test machines. Since release 14.11 the available tools are wsman and amttool for power-cycling and amtterm for grabbing the SOL output.

With this release, we added a community contribution for supporting meshcmd, which is available via GitHub and mentioned in Intel's release notes. The tool can be used as replacement for amtterm and wsman/amttool. Alternatively to the known amt-tool option wsman and amttool, meshcmd can now be specified as a RUN_OPT:

 RUN_OPT += --amt-tool meshcmd

Sections