genode/doc/release_notes/21-08.txt

              ===============================================
              Release notes for the Genode OS Framework 21.08
              ===============================================

                               Genode Labs



Genode 21.08 puts device drivers into the spotlight. It attacks the costs of
porting drivers from the Linux kernel and takes a leap forward with respect to
GPU support. This low-level work is complemented by several topics that
contribute to our vision of hosting video-conferencing scenarios natively on
Genode.

For those of you who follow Genode's release notes over the years, the
so-called DDE-Linux is a recurring topic. DDE is short for device-driver
environment and denotes our principal approach of running unmodified Linux
device-driver code inside Genode components. For over a decade, we iterated
many times to find a sustainable and scalable solution for satisfying Genode's
driver needs. Thanks to this enduring work, Genode enjoys support for modern
hardware such as Intel wireless chips or Intel graphics devices. However, when
looking beyond PC hardware, in particular at the plethora of ARM SoCs as
potential target platforms for Genode, we found our existing DDE-Linux
approach increasingly prohibitive because the investment of manual labour per
driver would become unbearable. It was time to recollect, draw from our
collective experience gathered over the past years, and re-envision what
DDE-Linux could be. Section [Linux-device-driver environment re-imagined]
presents the results of this recent line of development that promises to dwarf
the costs of driver-porting work compared to our time-tested approach. The
results have an immediate impact on our ambition to bring Genode to the
Pinephone as our added network and framebuffer drivers for the Allwinner A64
SoC leverage the new DDE already.

The challenge of using hardware-accelerated graphics (GPUs) on Genode makes a
guest appearance in the release notes on-and-off since version
[https://genode.org/documentation/release-notes/10.08#Gallium3D_and_Intel_s_Graphics_Execution_Manager - 10.08].
However, until now, GPU support has not become a commodity for Genode yet.
With the work presented in Section [Advancing GPU driver stack], we hope to
change that. For the first time, we identified a clear path to the
architectural integration of GPU support in sophisticated Genode scenarios
such as Sculpt OS. This outlook prompted us to revive the GPU stack in a
holistic way, including our custom Intel GPU multiplexer as well as the Mesa
stack.

Further highlights of the current release are an improved and updated version
of VirtualBox 6, refined user-level networking, the maturing integration with
host file systems when running Genode on top of Linux, and new media-playback
capabilities for our port of the Chromium web engine.


Linux-device-driver environment re-imagined
###########################################

Over more than a decade, the domestication of Linux device drivers for Genode
has evolved into a quest of almost epic proportions. This long-winded story
has been covered by a recent series of Genodians articles
([https://genodians.org/skalk/2021-04-06-dde-linux-experiments - first],
[https://genodians.org/skalk/2021-04-08-dde-linux-experiments-1 - second],
[https://genodians.org/skalk/2021-06-21-dde-linux-experiments-2 - third]),
which also goes into a technical deep dive of our recent developments.

On the one hand, we draw an enormous value from the device drivers of the
Linux kernel. Genode would be nowhere as useful without the Intel wireless
stack, USB host-controller drivers, or the Intel graphics driver that we
ported over from Linux. On the other hand, those porting efforts are draining
a lot of our energy. Linux kernel code is not designed for microkernel-based
systems after all. Consequently, the transplantation of such code does not
only require a solid understanding of Linux kernel internals, but also ways to
overcome the friction between two radically different operating-system-design
schools (monolithic and component-based) and friction between implementation
languages (C and C++).

Even though we are not short of evidence of successful driver ports, we are
very well aware of several elephants in the room:

Economically, each driver port must be understood as a distinct project of
non-trivial costs. E.g., the port of the i.MX8 graphics driver took us two
months. That's certainly minuscule compared to a driver written from scratch.
But it is still expensive and we feel that those expenses hold us back.

Second, once ported, later updates of drivers to a new kernel version are
costly and risky. But such updates are unavoidable to keep up with new
hardware. The larger the arsenal of device drivers, the bigger this problem
becomes.

Third, the skill set of the porting work is the cross point of Linux kernel
competence and Genode competence. In other words, it's rare. To make Genode
compatible to a broader spectrum of hardware in the long run, driver porting
must become an easily attainable skill rather than black art.

With the current release, we introduce a vastly improved approach to the reuse
of Linux device drivers on Genode. It entails three aspects:

:Code: Reusable building blocks for crafting custom runtime environments
  to bring Linux kernel code to fly, and for interfacing Genode's session
  interfaces with Linux kernel interfaces.

:Tooling: A custom tool set that automates repetitive work such as generating
  dummy implementations of Linux kernel functions.

:Methodology: Consistent patterns and exemplary test scenarios serving as
  guiding rails for the development work.

The following illustration maps out the first aspect, the various pieces of
code involved in hosting unmodified Linux driver code on Genode.
The clear separation of those parts reinforces a degree of formalism - in
particular about separating C and C++ - that was absent in our previous takes.

[image dde_linux_parts]

A driver is a Genode component. So the outer border of the picture is Genode's
bare-bones C++ API. At the lower end, the API provides access to device
resources such as interrupts and memory-mapped device registers. At the higher
end, the API allows the driver to play the role of a service for other
components through one of Genode's session interfaces.

The lower (blueish) part of the picture is concerned with the runtime
environment needed to make the Linux kernel code feel right at home. The gap
between Genode's API and Linux kernel interfaces is closed in two steps.
First, the so-called *lx_kit* library implements handy mechanisms for building
the meaty parts of the runtime in C++. For example, it provides a user-level
task scheduling model that satisfies the semantic needs of Linux. The lx_kit
is located at _dde_linux/src/include/lx_kit_ and _dde_linux/src/lib/lx_kit/_

Second, the *lx_emul* (short for Linux emulation) code wraps the lx_kit
functionality into C interfaces. The functions of those interfaces are
prefixed with 'lx_emul_' and serve as basic primitives for re-implementing
(parts of) the original Linux kernel-internal ABI. Although the previous
version of DDE Linux already featured the principle lx_kit and lx_emul
fragments, the new design applies the underlying idea much more stringent,
fostering the almost galvanic separation between C and C++ code. In
particular, C++ code never includes any Linux headers. The lx_emul code also
comprises driver-specific dummy implementations of unused kernel functions.
The handy tool at _tool/dde_linux/create_dummies_ automates the creation of
those dummy implementations now. Finally, the lx_emul code drives the startup
of the Linux kernel code by executing initcalls in the correct order. The
reusable building blocks of lx_emul are located at
_dde_linux/src/include/lx_emul/_ and _dde_linux/src/lib/lx_emul/_

When looking from the upper (greenish) end, the *genode_c_api* library is a
thin wrapper around Genode's session interfaces. It enables C code to
implement a Genode service such as block driver or network driver. The
genode_c_api library is located at _os/include/genode_c_api/_ and
_os/src/lib/genode_c_api/_.

The red area contains sole C code, most of which is unmodified Linux kernel
code. It is supplemented with a small *lx_user* part that uses both the
genode_c_api as well as Linux kernel interfaces to connect the unmodified
Linux kernel code with the Genode universe.

We address the second aspect - the tooling - by the growing tool set at
_tool/dde_linux/_. The biggest time saver is the _create_dummies_ tool, which
automates the formerly manual task of implementing dummy functions to quickly
attain a linkable binary. It is complemented with the _extract_initcall_order_
tool, which supplements lx_emul with the information needed to perform all
Linux initialization steps in the exact same order as a Linux kernel would do.

The third aspect - the methodology - is embodied in two source-code
repositories that leverage the new DDE-Linux approach for two distinct ARM
SoCs, namely i.MX8MQ and Allwinner A64.

:Genode support for i.MX8MQ SoC:

  [https://github.com/skalk/genode-imx8mq]

:Genode support for Allwinner A64 SoC:

  [https://github.com/nfeske/genode-allwinner]

The most pivotal methodological change is the way how we deal with the
Linux-internal API now. In our previous work, we used to mimic the content of
kernel headers by a custom-tailored emulation header _lx_emul.h_ per driver.
Whereas these driver-specific API flavors catered our urge to keep transitive
code complexity at bay, they required significant and boring manual labour.
Now we changed our minds to reusing the original Linux headers, thereby
greatly reducing the amount of repetitive work while reducing the likelihood
for subtle bugs.


Success stories
---------------

Both repositories linked above employ the re-imagined DDE-Linux approach to
resounding success. The i.MX8MQ repository features drivers for framebuffer
output and SD-card access,
[https://genodians.org/skalk/2021-08-02-mnt-reform2-sdcard - targeting the MNT Reform laptop].
The Allwinner repository contains a network driver for the Pine-A64-LTS board
and a new framebuffer driver for the Pinephone. No single line of Linux code
had to be changed.

We found that the development of those driver components took only a fraction
of time compared to our past experiences. The most unnerving aspects of the
driver porting work have simply vanished: Subtle incompatibilities between C
and C++ are ruled out by design now. The hunt for missing initcalls is no
more. No dummy function must be written by hand. The compilation of arbitrary
Linux compilation units works instantly without manual labour.
This - in turn - brings the experimental addition or removal of kernel
subsystems down from hours to seconds, turning the development work into an
exploratory experience.

That said, it is not all roses. Components based on Linux drivers have to
carry substantial Linux-specific bureaucracy along with them. The resulting
components tend to be somewhat obese given their relatively narrow purpose.
E.g., the executable binary of the framebuffer driver for the Pinephone is
1.5 MiB in size, most of which is presumably dead weight.


Transition
----------

Our existing and time-tested Linux-based drivers located in the _dde_linux_
repository have remained untouched by the current release.
We plan to successively update or replace those drivers using the new
approach. Until then, the original components refer to the old approach as
"legacy". E.g., the former implementation of lx_emul has been moved to
_dde_linux/src/include/legacy/lx_emul/_.


Advancing GPU driver stack
##########################

With release 21.08, we take a major leap towards 3D and GPU support on Genode.
This topic has been on the slow burner for a while now and we were happy to be
able to finally revive this topic. On the Mesa front, we conducted an update
to version 21.0.0 (Section [Mesa update]), while adding more features and new
platforms to our
[https://genode.org/documentation/release-notes/17.08 - Intel GPU multiplexer].
On Intel platforms, there exists no hardware distinction between the display
controller and 3D acceleration, as both functions are provided by the GPU.
Other platforms, e.g. ARM based SoCs, often contain a separate display and a
GPU device, making it possible to isolate display configuration within a
separate driver. Therefore, we are glad to report that we found a solution on
how to separate display and 3D acceleration on Intel systems.


Mesa update
-----------

Genode's port of the
[https://www.mesa3d.org - Mesa 3D graphics library] dates back to version
11.2.2 that was released in 2016 while the current version is past 21 by now.
Because of this version gap, we decided to start with a fresh port of Mesa
instead of solely updating from version 11. The more recent version enabled us
to switch from Mesa's DRI drivers (i965) to the
[https://de.wikipedia.org/wiki/Gallium3D - Gallium] version (Iris) for Intel
GPUs.
[https://xdc2018.x.org/slides/optimizing-i965-for-the-future.pdf - Iris]
is Intel's redesigned version of the dated i965 driver that aims to lower CPU
usage and improved performance. It is the only driver that supports Gen 12
(Intel's current Xe GPU architecture) while also removing support for old
Intel generations. As Genode supports Gen 8 (Broadwell) platforms only, we
felt that Iris is the driver of choice for the future.


GPU multiplexer improvements
----------------------------

The GPU multiplexer received stability improvements, new features required by
Mesa's Iris driver, i.e. context isolation and sync objects, and bug fixes
prompted by supporting newer GPU generations. These generations include Gen 9
(Skylake) and Gen 9.5 (Kaby Lake), with more versions to come. Please note
that this line of work is not finished and is as of now in a preliminary state
with ongoing efforts.


The GPU multiplexer as a platform service
-----------------------------------------

As stated at the beginning of this chapter, Intel PC platforms have no
distinction between the display device and the 3D rendering. Both functions
are integrated into the GPU as display engine and render engine. This implies
that Genode's Intel framebuffer/display driver has to share resources with the
GPU multiplexer. The co-location of both drivers in one component, however,
violates Genode's core principle of a minimally-complex trusted computing
base. Whereas the complex display driver should best be a disposable component
([https://fosdem.org/2021/schedule/event/microkernel_pluggable_device_drivers_for_genode/ - FOSDEM talk]),
the GPU driver must ideally be realized as a low-complexity resource
multiplexer.

We eventually found a way to solve this contradiction: On Genode, each driver
requests the hardware resources to program a device from the platform driver
via the platform session. As these resources cannot be shared, we came up with
the idea that the GPU multiplexer requests all GPU resources and itself
provides a platform service for the display driver. It hands out the subset of
resources that are related to display handling and forwards display
interrupts. This approach is completely transparent to Genode's Intel display
driver.

[image gpu_architecture]
  System integration of the GPU driver/multiplexer and the framebuffer driver
  as distinct components

We already have implemented this solution for Gen 8 and are working on newer
generations.


Future prospects
----------------

In the current state, we are still working on newer Intel (Gen9+) GPU support
and are planning to integrate this line of work into Sculpt release 21.09 with
a small demo scenario (e.g., [https://github.com/glmark2/glmark2 - Glmark2]
that is now available in Genode world).

Additionally, there is ongoing work to support
[https://www.verisilicon.com/en/IPPortfolio/VivanteGPUIP - Vivante] GPUs as
utilized by i.MX SoCs. As of now Mesa's etnaviv driver is included in our
Mesa update and a GPU multiplexer component based on the Linux DRM driver is
available as a preview on
[https://github.com/cnuke/genode/commits/21.08-etnaviv - this] topic branch.


Base framework and OS-level infrastructure
##########################################

Revised cache-maintenance interface
===================================

The base library used to expose a single cache-maintenance function to
user-level components, namely 'cache_coherent'. It is primarily needed to
accommodate self-modifying code, e.g., for JIT compilers, to write back
data-cache lines, and invalidate the corresponding instruction-cache lines.
However, we found that the proper support for cached DMA buffers in Linux
device-driver ports calls for two additional semantic flavours.

One is needed whenever driver code initially writes data to a DMA buffer
before handing over the buffer to the device. Linux driver code usually issues
a 'dma_map_*' call in this case to ensure that data gets written out to memory
and the data cache is invalidated. This scenario is now covered by the new
'cache_clean_invalidate_data' function.

The other flavor is needed to invalidate data-cache lines before reading
device-generated content from a DMA buffer. Linux driver code usually calls a
'dma_unmap_*' function in this case. This case is now covered by the new
'cache_invalidate_data' function.

Both functions are provided for the base-hw and Fiasco.OC kernels on the ARM
architecture.


Improved host file-system access on Genode/Linux
================================================

Genode has included a component for host file-system access on Linux for
years, but the state of the implementation and the feature set limited its
application to mere debugging or development scenarios. This release improves
*lx_fs* in certain areas to permit common use cases and scenarios.

First, the file-system server gets support for the unlinking of files, which
was left out in the past to prevent accidental deletion of files on the host.
The current version includes a robust implementation of the feature, which is
confined to the configured sub-directory.
Further, sessions track client-specific consumption of resources (namely RAM
and capabilities) and also support dynamic resource upgrades. Last, we added
file-watching support to lx_fs, which enables monitoring files for changes
based on the inotify interface of the Linux kernel. The implementation is
prepared to handle bursts of changes by limiting the rate of notifications to
the client.

These improvements were contributed by Pirmin Duss.


New black-hole component
========================

A commonly requested feature for Sculpt OS is that it would be nice to have
the ability to wire up various sessions of a deployed component to a dummy
version of the required service. This way, the user could easily start an
application that would normally require, for example, an audio-out session but
connect it to a "black hole" component that simply drops all audio data. This
would be especially useful if no hardware driver for a specific device is
available on a particular platform, but would also allow for more fine-grained
privacy control.

For this release, we created a first version of the black-hole component,
which provides a dummy implementation of the audio-out session when enabled in
the configuration:

! <config>
!   <audio_out/>
! </config>

More session types are intended to be added in future releases.


NIC router
==========

With this release, the NIC router receives an enhancement of its feature for
forwarding DNS configurations via DHCP, a sensible way of dealing with
fragmented IPv4 packets, and some minor cleanups regarding its configuration
interface. The update changes the configuration interface of the NIC router in
a non-compatible way. Hence, systems that integrate the router might require
adaptation. At the end of this section, you can find an overview of how to
adapt systems properly.

The NIC router now interprets the IPv4 flags "More Fragments" and "Fragment
Offset" in order to determine whether an IPv4 packet is fragmented or not.
Fragmented packets are dropped safely while the unfragmented ones are routed
as usual. The decision to drop fragmented packets by default is the result of
a long discussion among users and developers of the NIC router. That
discussion came to the conclusion that the complexity overhead and security
risks of routing fragmented IPv4 outrun its relevance in modern world
networks. Therefore, we assume that for the common user of the router, a
simple rejection of fragmented IPv4 is the better deal.

The consideration of IPv4 fragmentation is accompanied by several ways of
communicating the router's decision to drop fragmented packets. If the config
flag 'verbose_packet_drop' is set, the router prints a message "drop packet
(fragmented IPv4 not supported)" for each dropped fragment to the log. If the
new attribute 'dropped_fragm_ipv4' in the config tag '<report>' is set, the
router will report the number of packets dropped due to fragmentation. Last
but not least, the NIC router can also be instructed to inform the sender of a
dropped IPv4 fragment by sending an ICMP "destination unreachable" reply. Like
the other feedback mechanisms, this is deactivated by default and can be
activated by setting the new config attribute 'icmp_type_3_code_on_fragm_ipv4'.
The attribute must be set to a valid ICMP code number that is then used for
the replies.

The run script 'nic_router_ipv4_fragm' demonstrates the router's behavior
regarding fragmented IPv4.

For many years, the DHCP server of the NIC router is capable of sending DNS
configuration attributes with its replies. At first, this was only a single
DNS server address. With
[https://genode.org/documentation/release-notes/21.02#NIC_router - Genode 21.02],
this has been extended to a list of DNS server addresses. Sending such address
lists has now been made more conforming to the RFCs in that the server will
list them all in one option 6 field instead of adding one option 6 field per
address. Consequently, the DHCP client of the router now also considers only
the first option 6 field of a reply but may parse multiple addresses from it.

Another new feature is that the DHCP client of the router now remembers the
domain name (option 15) of a DHCP reply that leads to an IPv4 configuration.
Analogously, the DHCP server will send a domain name with DHCP replies if such
a name is at hand. As with DNS server addresses, the DHCP server can obtain
the domain name either statically through its configuration (new config tag
'<dns-domain>') or dynamically from the results of a DHCP client of another
domain. The latter is achieved by setting the new config attribute
'dns_config_from' that replaces the former attribute 'dns_server_from'. If
'dns_config_from' is set to the name of another domain, the DHCP server will
use both the DNS server addresses and the DNS domain name of the domain.

DNS domain names that were stored with a dynamic IPv4 configuration in the
router are also reported via the new report tag '<dns-domain>' whenever the
'config' attribute in the config tag '<report>' is set. As with DNS server
addresses, this allows for manual forwarding and filtering through individual
management components (see
[https://genode.org/documentation/release-notes/21.02#NIC_router - Genode 21.02]).

As a delayed adaption to the
[https://genode.org/documentation/release-notes/21.02#Pluggable_network_device_drivers - introduction of the Uplink session]
two Genode releases ago, the term "Uplink", that was used in combination with
the NIC router to refer to NIC sessions that the router requested itself, has
been re-named more accurately to "NIC client". This is meant to prevent
confusion with the new session type and, most notable to users, implies that
the tag '<uplink>' in router configurations got re-named to '<nic-client>'.


How to adjust Genode 21.05 systems to the new NIC router
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

* At each occurrence of the '<uplink ...>' tag in a NIC router configuration,
  replace the tag name 'uplink' with 'nic-client'. The rest of the tag stays
  the same. This does not yield any semantic changes.

* At each occurrence of the 'dns_server_from' attribute in a NIC router
  configuration, replace the attribute name with 'dns_config_from'. The
  attribute value remains unaltered. Be aware that this will add forwarding of
  DNS domain names to your system. Forwarding DNS server addresses but not DNS
  domain names is not supported anymore.


RAM framebuffer driver for Qemu
===============================

During graphical application development on ARMv8, it became obvious that
Genode still lacked framebuffer-driver support on Qemu for ARMv8, thus
rendering test execution on real hardware mandatory. In order to speedup test
and development time for graphical applications, we enabled RAM framebuffer
support for the "virt_qemu" board by adding a 'driver_interactive-virt_qemu'
package. The package contains a 'ram_fb_drv' that configures a RAM framebuffer
through Qemu's firmware interface and uses the capture session interface to
provide access to the framebuffer.

To test drive the driver, you can execute any Genode run script that requires
graphical applications. The following example shows how to execute the demo
run script in Qemu:

* In _<genode_dir>/build/arm_v8a/etc/build.conf_ change
  ! # use time-tested graphics backend
  ! QEMU_OPT += -display sdl

  to

  ! QEMU_OPT += -device ramfb

* In _<genode_dir>/build/arm_v8a_ execute
  ! make KERNEL=hw BOARD=virt_qemu run/demo


Sandbox API
===========

When using [https://github.com/nfeske/goa - Goa], we noticed that using the os
API caused binaries to be always linked against 'sandbox.lib.so' because its
symbols were part of the api archive as well. We therefore decided to separate
the sandbox API from the os API by moving the header files to
_repos/os/include/sandbox/_ and providing them in a distinct api archive along
with the library symbols.


Libraries and applications
##########################

Updated and improved VirtualBox
===============================

Our ongoing development efforts with VirtualBox 6.1 extended the
implementation in various aspects. With this release, we updated the version
to 6.1.26 published in July to stay in sync with upstream developments. This
version especially improves the audio back end for the OSS interface and
graphics.

On the integration side, VirtualBox 6 now supports dynamic framebuffer
resolutions and the capslock ROM mode. The latter is important to provide the
user a consistent system-wide capslock state, which is controlled by a global
capslock ROM and virtual KEY_CAPSLOCK events forwarded to guest operating
systems. Per default, a raw mode is used and capslock input events are sent
unfiltered to the guest. For ROM mode, VirtualBox may be configured like
follows.

!<config capslock="rom">

The network-device model in VirtualBox 5 uses the MAC address from the
connected NIC session. We added this behavior also to VirtualBox 6. During the
past months, we also observed significant performance issues with the AHCI
model, which we address in this release. The background is that our port of
VirtualBox 6 limits changes to the original code and execution model to a bare
minimum. This renders updates of the upstream version less expensive, but on
the other hand, uncovers some inherent assumptions about the runtime behavior
(i.e., scheduling of threads) in the original implementation that must be
addressed.


Qt5 and QtWebEngine
===================

In this release, we enabled SSL server certificate validation and support for
multimedia playback in our ports of QtWebEngine and the Falkon web browser.

More specifically, we ported the 'nss' library for the SSL certificate
validation and the 'sndio' library as back end for the audio playback
functionality and enhanced our OSS audio VFS plugin accordingly.

The following screenshot shows an example use case of Falkon as a private
multimedia browser, which stores all session data, like cookies, in RAM only.
In the future, we also want to enable support for multimedia input and,
consequently, private video conferences.

[image falkon_youtube]


Modular integration of LTE modem stack in Sculpt OS
===================================================

In version [https://genode.org/documentation/release-notes/21.02#LTE_modem_stack - 21.02],
we announced the LTE modem support as a prerequisite for using Genode on the
Pinephone. Since most of our development laptops also come with LTE modems or
an extension slot for installing one, we explored ways to augment the Sculpt
scenario with mobile networking on demand, i.e., by the installation of
additional components. The result is documented by means of an
[https://genodians.org/jschlatow/2021-07-21-mobile-network - article on genodians.org].


Webcam improvements using libuvc
================================

With webcam support added by the previous release, we discovered some
complications with devices that implement the UVC spec in version 1.5. We
found one of those devices in a Thinkpad T490s. Since
[https://ken.tossell.net/libuvc/doc - libuvc] did not fully implement this
version of the spec, we added a patch for this. The main issue was the
different size of the video probe and commit control messages. Interestingly,
the problematic device is quite picky in this regard and only responds when
the size was set correctly. In connection with this, we fixed a bug in our
[https://libusb.info - libusb] back end, which caused the size of USB control
messages being wrongly calculated.

Apart from these device-specific issues, the webcam driver now enables auto
exposure in order to adapt to different lighting conditions.


Sndio audio library
===================

To complement the VFS OSS-plugin introduced in release
[https://genode.org/documentation/release-notes/20.11 - 20.11], we ported the
[https://sndio.org - sndio] library to Genode. It contains an OSS back end
that prompted us to broaden the functionality of our VFS plugin to satisfy
the requirements of the library. This is in line with the envisioned plan to
extend the OSS plugin incrementally to cover more use cases.

The sndio framework features a server component besides the library but for
the moment, we focus solely on using sndio in a client context. Here the
component, e.g., cmus and Falkon, uses the library to access the sound device
directly.


Build system and tools
######################

Tool-chain support for RISC-V
=============================

As one might have noticed, Genode's RISC-V tool chain is absent in tool-chain
release
[https://sourceforge.net/projects/genode/files/genode-toolchain/21.05/genode-toolchain-21.05-x86_64.tar.xz/download - 21.05]
because it still had issues at the release time. These issues, namely the
problem of the dynamic linker's self relocation during program startup have
been resolved during this release cycle. The RISC-V tool chain can now be
built manually using Genode's regular 'tool_chain' script:

! <genode-dir>/tool/tool_chain riscv ENABLE_FEATURES="c c++ gdb"


Run tool
========

Genode's custom workflow automation tool called 'run' received the following
enhancements.

To ease the hosting of driver packages outside of Genode's main repository -
an emerging pattern for supporting new SoCs - we replaced the formerly
built-in names of board-specific 'drivers_nic' and 'drivers_interactive' depot
packages by the convention of appending the board name as a suffix, e.g.,
'drivers_nic-pine_a64lts'. Hence, new hardware support can now be added
without touching the run tool.

The ARM fastboot plugin can now be used on 64-bit ARM platforms in addition to
32-bit ARM. Its formerly mandatory parameter '--load-fastboot-device' has
become optional and can be omitted if only one device is present.

A new _image/uboot_fit_ plugin enables the use of U-Boot's new FIT (flattened
image tree) image format (carrying the extension 'itb'), which supersedes the
uImage format. The new format simplifies the booting of a Linux system, which
typically requires not only a kernel image but also a device-tree binary and a
RAM disk. A FIT image combines all ingredients into a single file and adds
some metadata like checksums. Note, however, that booting an _image.itb_,
which doesn't contain a device-tree binary may cause U-Boot's 'bootm' command
to fail. A workaround for this is to execute the individual boot steps
separately, which skips the Linux-specific preparatory steps that depend on
the device-tree binary:

! bootm start
! bootm loados
! bootm go


Removal of deprecated components
################################

In the release notes of version
[https://genode.org/documentation/release-notes/20.11#Retiring_the_monolithic_USB_driver - 20.11],
we announced the retirement of our traditional monolithic USB-driver
component, which used to combine host-controller drivers together with USB
storage, HID, and networking drivers in a single component. With the current
release, we ultimately completed the transition to our multi-component USB
stack and removed the deprecated monolithic USB driver.