depot: update recipe hashes

This patch adds the handling neccessary for clients to upgrade the cap
quota of their GUI session. Until now, the upgrade mechanism supported
only RAM quota.

The limitation became visible once a client - in the particular case the
motif_decorator - attempted the cap upgrade of its GUI session. The cap
quota would arrive at the wm, but the wm would keep it instead of
forwarding the quota to nitpicker. This resulted in an infinite retry
loop at the motif_decorator, ultimatedly depleting all its cap quota.

README

@@ -65,34 +65,24 @@ The source tree is composed of the following subdirectories:
 
 :'doc':
 
-  This directory contains general documentation. Please consider the following
-  document for a quick guide to get started with the framework:
-
-  ! doc/getting_started.txt
-
-  If you are curious about the ready-to-use components that come with the
-  framework, please review the components overview:
-
-  ! doc/components.txt
+  This directory contains general documentation along with a comprehensive
+  collection of release notes.
 
 :'repos':
 
-  This directory contains the so-called source-code repositories of Genode.
-  Please refer to the README file in the 'repos' directory to learn more
-  about the roles of the individual repositories.
+  This directory contains the source code, organized in so-called source-code
+  repositories. Please refer to the README file in the 'repos' directory to
+  learn more about the roles of the individual repositories.
 
 :'tool':
 
   Source-code management tools and scripts. Please refer to the README file
   contained in the directory.
 
-:'depot' and 'public':
+:'depot':
 
-  Local depot and public archive of Genode packages. Please refer to
-
-  ! doc/depot.txt
-
-  for more details.
+  Directory used by Genode's package-management tools. It contains the public
+  keys and download locations of software providers.
 
 
 Additional community-maintained components

VERSION

@@ -1 +1 @@
-20.08
+21.02

doc/coding_style.txt

@@ -93,6 +93,24 @@ and the source code always looks good.
 _Hint:_ In VIM, use the 'set list' and 'set listchars' commands to make tabs
 and spaces visible.
 
+* If class initializers span multiple lines, put the colon on a separate
+  line and indent the initializers using one tab. For example:
+  ! Complicated_machinery(Material &material, Deadline deadline)
+  ! :
+  ! <tab>_material(material),
+  ! <tab>_deadline(deadline),
+  ! <tab>...
+  ! {
+  !      ...
+  ! }
+
+* Preferably place statements that alter the control flow - such as
+  'break', 'continue', or 'return' - at the beginning of a separate line,
+  followed by vertical space (a blank line or the closing brace of the
+  surrounding scope).
+  ! if (early_return_possible)
+  !     return;
+
 
 Switch statements
 ~~~~~~~~~~~~~~~~~

doc/components.txt

@@ -35,7 +35,7 @@ of them is briefly characterized as follows:
   one of Genode's device-independent session interfaces, which are
   'platform_session', 'capture_session', 'event_session', 'block_session',
   'audio_out_session', 'log_session', 'nic_session', and 'timer_session'
-  (see 'os/include/' for the interface definitions). Those interfaces are
+  (see _os/include/_ for the interface definitions). Those interfaces are
   uniform across hardware platforms and kernel base platforms. Usually,
   each device driver can accommodate only one client at a time.
 
@@ -64,7 +64,7 @@ of them is briefly characterized as follows:
 Device drivers
 ##############
 
-Device drivers usually reside in the 'src/drivers' subdirectory of source-code
+Device drivers usually reside in the _src/drivers/_ subdirectory of source-code
 repositories. The most predominant repositories hosting device drivers are
 'os', 'dde_ipxe', 'dde_linux'.
 
@@ -72,23 +72,23 @@ repositories. The most predominant repositories hosting device drivers are
 Platform devices
 ================
 
-:'os/src/drivers/platform/': Platform drivers for various platforms.
+:_os/src/drivers/platform/_: Platform drivers for various platforms.
   On x86, the platform driver uses the PCI controller as found on x86 PC
   hardware. A client can probe for a particular device and request information
   about physical device resources (using the 'platform_device' interface). I/O
   resources for MMIO regions, I/O ports, and interrupts can be requested by the
   provided device abstraction.
 
-:'os/src/drivers/acpi':
+:_os/src/drivers/acpi/_:
   On x86 platforms that use the APIC (namely Fiasco.OC, NOVA, and hw_x86_64)
   this simple ACPI parser traverses the ACPI tables and reports device-resource
   information (e.g., interrupt lines of PCI devices).
 
-:'os/src/app/smbios_decoder':
+:_os/src/app/smbios_decoder/_:
   A component that parses SMBIOS information on x86 platforms and makes the
   result available as a report.
 
-:'libports/src/app/acpica':
+:_libports/src/app/acpica/_:
   In addition to our ACPI base driver, the acpica component uses the
   ACPICA library to provide access to dynamic functions like battery
   states, events (e.g., notebook lid close and power buttons), as well
@@ -102,10 +102,10 @@ UART devices
 
 The UART device drivers implement the UART-session interface.
 
-:'os/src/drivers/uart/spec/pbxa9':
+:_os/src/drivers/uart/spec/pbxa9/_:
   Driver for the PL011 UART as found on many ARM-based platforms.
 
-:'os/src/drivers/uart/spec/x86':
+:_os/src/drivers/uart/spec/x86/_:
   Driver for the i8250 UART as found on PC hardware.
 
 
@@ -115,60 +115,62 @@ Framebuffer and input drivers
 Framebuffer and input drivers are implemented as clients of the
 capture-session and event-session interfaces respectively.
 
-:'os/src/drivers/ps2/x86':
+:_os/src/drivers/ps2/x86/_:
   Driver for the 'i8042' PS/2 controller as found in x86 PCs. It supports both
   mouse (including ImPS/2, ExPS/2) and keyboard.
 
-:'os/src/drivers/ps2/pl050':
+:_os/src/drivers/ps2/pl050/_:
   Driver for the PL050 PS/2 controller as found on ARM platforms such as
   VersatilePB. The physical base address used by the driver is obtained at
-  compile time from a header file called 'pl050_defs.h'. The version of the
-  VersatilePB platform can be found at 'os/include/platform/vpb926/' and
+  compile time from a header file called _pl050_defs.h_. The version of the
+  VersatilePB platform can be found at _os/include/platform/vpb926/_ and
   is made available to the driver via the SPECS machinery of the Genode build
   system.
 
-:'libports/src/drivers/framebuffer/vesa':
+:_libports/src/drivers/framebuffer/vesa/_:
   Driver using VESA mode setting on x86 PCs. For more information, please refer
   to the README file in the driver directory.
 
-:'libports/src/drivers/framebuffer/boot':
+:_libports/src/drivers/framebuffer/boot/_:
   Driver for boot-time initialized framebuffers (e.g., UEFI GOP)
   discovered from the 'platform_info' ROM
 
-:'os/src/drivers/framebuffer/pl11x':
+:_os/src/drivers/framebuffer/pl11x/_:
   Driver for the PL110/PL111 LCD display.
 
-:'os/src/drivers/framebuffer/imx53':
+:_os/src/drivers/framebuffer/imx53/_:
   Driver for LCD output on i.MX53 SoCs.
 
-:'os/src/drivers/framebuffer/rpi':
+:_os/src/drivers/framebuffer/rpi/_:
   Driver for the HDMI output of the Raspberry Pi.
 
-:'os/src/drivers/framebuffer/sdl':
+:_os/src/drivers/framebuffer/sdl/_:
   Serves as both framebuffer and input driver on Linux using libSDL. This
   driver is only usable on the Linux base platform.
 
-:'os/src/drivers/gpu/intel':
+:_os/src/drivers/gpu/intel/_:
   An experimental Intel Graphics GPU multiplexer for Broadwell and newer.
 
-:'dde_linux/src/drivers/framebuffer/intel':
+:_dde_linux/src/drivers/framebuffer/intel/_:
   Framebuffer driver for Intel i915 compatible graphic cards based on
   the Linux Intel KMS driver.
 
-:'dde_linux/src/drivers/usb':
-  USB driver that makes USB HID and USB storage devices available as an input
-  event stream and a block session respectively. For examples of using this
-  driver, refer to the run scripts at 'dde_linux/run/usb_hid' and
-  'dde_linux/run/usb_storage'.
+:_dde_linux/src/drivers/usb_host/_:
+  USB host-controller driver that provides an USB session interface to
+  USB drivers.
 
-:'dde_linux/src/drivers/usb_hid':
+:_dde_linux/src/drivers/usb_hid/_:
   USB Human Interface Device driver using the USB session interface.
 
+:_os/src/drivers/usb_block/_:
+  USB storage driver that uses the USB session interface and provides
+  a block-session interface.
+
 
 Timer drivers
 =============
 
-The timer driver located at 'os/src/drivers/timer' implements the timer-session
+The timer driver located at _base/src/timer/_ implements the timer-session
 interface. Technically, it is both a device driver (accessing a timer
 device) and a resource multiplexer (supporting multiple timer-session clients
 at the same time). Depending on the base platform, the implementation uses
@@ -189,13 +191,13 @@ Audio drivers
 =============
 
 Audio drivers implement the Audio_out session interface defined at
-'os/include/audio_out_session/' for playback and optionally the audio_in
+_os/include/audio_out_session/_ for playback and optionally the audio_in
 interface for recording.
 
-:'os/src/drivers/audio/spec/linux':
+:_os/src/drivers/audio/spec/linux/_:
   Uses ALSA as back-end on the Linux base platform and supports only playback.
 
-:'dde_bsd/src/drivers/audio':
+:_dde_bsd/src/drivers/audio/_:
   Sound drivers ported from OpenBSD. Currently, the repository
   includes support for Intel HD Audio as well as for Ensoniq AudioPCI
   (ES1370) compatible sound cards.
@@ -205,31 +207,31 @@ Block drivers
 =============
 
 All block drivers implement the block-session interface defined at
-'os/include/block_session/'.
+_os/include/block_session/_.
 
-:'os/src/drivers/sd_card/spec/pl180':
+:_os/src/drivers/sd_card/spec/pl180/_:
   Driver for SD-cards connected via the PL180 device as found on the PBX-A9
   platform.
 
-:'os/src/drivers/sd_card/spec/imx53':
+:_os/src/drivers/sd_card/spec/imx53/_:
   Driver for SD-cards connected to the Freescale i.MX53 platform like the
   Quick Start Board or the USB armory device.
 
-:'os/src/drivers/sd_card/spec/rpi':
+:_os/src/drivers/sd_card/spec/rpi/_:
   Driver for SD-cards connected to the Raspberry Pi.
 
-:'dde_linux/src/drivers/usb':
+:_dde_linux/src/drivers/usb/_:
   USB driver that makes USB storage devices available as block sessions.
   For an example of using this driver, refer to the run script at
-  'dde_linux/run/usb_storage'.
+  _dde_linux/run/usb_storage.run_.
 
-:'os/src/drivers/ahci':
+:_os/src/drivers/ahci/_:
   Driver for SATA disks and CD-ROMs on x86 PCs.
 
-:'os/src/drivers/nvme':
+:_os/src/drivers/nvme/_:
   Driver for NVMe block devices on x86 PCs.
 
-:'os/src/drivers/usb_block':
+:_os/src/drivers/usb_block/_:
   USB Mass Storage Bulk-Only driver using the USB session interface.
 
 
@@ -237,45 +239,45 @@ Network interface drivers
 =========================
 
 All network interface drivers implement the NIC session interface
-defined at 'os/include/nic_session'.
+defined at _os/include/nic_session/_.
 
-:'os/src/drivers/nic/spec/linux':
+:_os/src/drivers/nic/spec/linux/_:
   Driver that uses a Linux tap device as back end. It is only useful on the
   Linux base platform.
 
-:'os/src/drivers/nic/spec/lan9118':
+:_os/src/drivers/nic/spec/lan9118/_:
   Native device driver for the LAN9118 network adaptor as featured on the
   PBX-A9 platform.
 
-:'dde_ipxe/src/drivers/nic':
+:_dde_ipxe/src/drivers/nic/_:
   Device drivers ported from the iPXE project. Supported devices are Intel
   E1000 and pcnet32.
 
-:'dde_linux/src/drivers/wifi':
+:_dde_linux/src/drivers/wifi/_:
   The wifi_drv component is a port of the Linux mac802.11 stack, including the
   iwlwifi driver. It enables the use of Intel Wireless 6xxx and 7xxx cards.
 
-:'dde_linux/src/drivers/usb':
+:_dde_linux/src/drivers/usb/_:
   For the OMAP4 platform, the USB driver contains the networking driver.
 
-:'dde_linux/src/drivers/nic/fec':
+:_dde_linux/src/drivers/nic/fec/_:
   Driver for ethernet NICs of the i.MX SoC family.
 
 
 General-purpose I/O drivers
 ===========================
 
-:'os/src/drivers/gpio/spec/imx53':
+:_os/src/drivers/gpio/spec/imx53/_:
   Driver for accessing the GPIO pins of i.MX53 platforms.
 
-:'os/src/drivers/gpio/spec/rpi':
+:_os/src/drivers/gpio/spec/rpi/_:
   Driver for accessing the GPIO pins of Raspberry Pi platforms.
 
 
 Resource multiplexers
 #####################
 
-By convention, resource multiplexers are located at the 'src/server'
+By convention, resource multiplexers are located at the _src/server/_
 subdirectory of a source repository.
 
 :Framebuffer and input: Framebuffer and input devices can be multiplexed using
@@ -285,35 +287,35 @@ subdirectory of a source repository.
   service for input drivers, a capture service for output drivers, and a GUI
   service for the applications. Each GUI session contains a virtual
   framebuffer and a virtual input interface. Nitpicker (including a README
-  file) is located at 'os/src/server/nitpicker'.
+  file) is located at _os/src/server/nitpicker/_.
 
-:Audio output: The audio mixer located at 'os/src/server/mixer' enables
+:Audio output: The audio mixer located at _os/src/server/mixer/_ enables
   multiple clients to use the audio-out interface. The mixing is done by simply
   adding and clamping the signals of all present clients.
 
-:Networking: The NIC bridge located at 'os/src/server/nic_bridge' multiplexes
+:Networking: The NIC bridge located at _os/src/server/nic_bridge/_ multiplexes
   one NIC session to multiple virtual NIC sessions using a proxy-ARP
   implementation. Each client has to obtain a dedicated IP address visible to
   the physical network. DHCP requests originating from the virtual NIC sessions
   are delegated to the physical network.
 
-  The NIC router located at 'os/src/server/nic_router' multiplexes one NIC
+  The NIC router located at _os/src/server/nic_router/_ multiplexes one NIC
   session to multiple virtual NIC sessions by applying network address
   translation (NAT).
 
-:Block: The block-device partition server at 'os/src/server/part_block' reads
+:Block: The block-device partition server at _os/src/server/part_block/_ reads
   the partition table of a block session and exports each partition found as
   separate block session. For using this server, please refer to the run
-  script at 'os/run/part_block'.
+  script at _os/run/part_block.run_.
 
 :File system: The VFS file-system server allows multiple clients to
   concurrently access the same virtual file system. It is located at
-  'os/src/server/vfs'. The VFS can be assembled out of several builtin
+  _os/src/server/vfs/_. The VFS can be assembled out of several builtin
   file-system types (like a RAM file system, or pseudo file systems for
   various Genode session interfaces) as well as external plugins such as rump
   (mounting file systems supported by the NetBSD kernel).
 
-:Terminal: The terminal_mux service located at gems/src/server/terminal_mux
+:Terminal: The terminal_mux service located at _gems/src/server/terminal_mux/_
   is able to provide multiple terminal sessions over one terminal-client
   session. The user can switch between the different sessions using a keyboard
   shortcut, which brings up an ncurses-based menu.
@@ -328,127 +330,123 @@ one session interface to another, or in the form of libraries.
 Separate components
 ===================
 
-:'os/src/server/gui_fb':
+:_os/src/server/gui_fb/_:
   Translates a GUI session to a pair of framebuffer and input sessions.
   Each 'gui_fb' instance is visible as a rectangular area on screen presenting
   a virtual frame buffer. The area is statically positioned. For more
-  information, please refer to 'os/src/server/gui_fb/README'.
+  information, please refer to _os/src/server/gui_fb/README_.
 
-:'gems/src/server/wm':
+:_gems/src/server/wm/_:
   Window manager that implements the GUI session interface but manages
   each client view as a separate window. The window decorations are provided
-  by a so-called decorator (e.g., 'gems/src/app/decorator'). The behaviour
+  by a so-called decorator (e.g., _gems/src/app/decorator/_). The behaviour
   is defined by a so-called window layouter such as the floating window
-  layouter located at 'gems/src/app/floating_window_layouter/'.
+  layouter located at _gems/src/app/floating_window_layouter/_.
 
-:'demo/src/server/liquid_framebuffer':
+:_demo/src/server/liquid_framebuffer/_:
   Implements the same translation as 'gui_fb' but by presenting an interactive
   window rather than a statically positioned screen area.
 
-:'os/src/server/tar_rom':
+:_os/src/server/tar_rom/_:
   Provides each file contained in a tar file obtained via Genode's ROM session
   as separate ROM session.
 
-:'os/src/server/iso9660':
+:_os/src/server/iso9660/_:
   Provides each file of an ISO9660 file system accessed via a block session as
   separate ROM session.
 
-:'os/src/server/lx_fs':
+:_os/src/server/lx_fs/_:
   A file system server that makes the file system of a Linux base platform
   available to Genode.
 
-:'os/src/server/rom_block':
-  Provides the content of a ROM file as a block session, similar to the
-  loop-mount mechanism on Linux
+:_os/src/server/vfs_block/_:
+  Provides the content of a file obtained from a VFS as a block session,
+  similar to the loop-mount mechanism on Linux
 
-:'os/src/server/ram_block':
-  Provides the content of a RAM dataspace as a block session. In contrast
-  to 'rom_block', this server provides a writeable block device.
-
-:'os/src/server/terminal_log':
+:_os/src/server/terminal_log/_:
   Adapter for forwarding LOG messages to a terminal session.
 
-:'os/src/server/log_terminal':
+:_os/src/server/log_terminal/_:
   Adapter for forwarding terminal output to a LOG session.
 
-:'os/src/server/fs_log':
+:_os/src/server/fs_log/_:
   Adapter that writes LOG messages to files on a file system.
 
-:'demo/src/server/nitlog':
+:_demo/src/server/nitlog/_:
   Provides a LOG session, printing log output on screen via a GUI session.
 
-:'os/src/app/rom_logger':
+:_os/src/app/rom_logger/_:
   The rom_logger component requests a ROM session and writes the
   content of the ROM dataspace to the LOG.
 
-:'os/src/server/rom_filter':
+:_os/src/server/rom_filter/_:
   The ROM filter provides a ROM module that depends on the content of
   other ROM modules steered by the filter configuration, e.g., dynamic
   switching between configuration variants dependent on the state of
   the system.
 
-:'os/src/server/log_terminal':
+:_os/src/server/log_terminal/_:
   Forwards terminal output to a LOG session.
 
-:'gems/src/server/file_terminal':
+:_gems/src/server/file_terminal/_:
   Provides terminal sessions that target files on a file system.
 
-:'gems/src/server/terminal':
+:_gems/src/server/terminal/_:
   Provides a terminal session via a graphical terminal using a framebuffer
   session and an input session.
 
-:'gems/src/server/tcp_terminal':
+:_gems/src/server/tcp_terminal/_:
   Provides one or multiple terminal sessions over TCP connections.
-  For further information, refer to 'gems/src/server/tcp_terminal/README'.
+  For further information, refer to _gems/src/server/tcp_terminal/README_.
 
-:'os/src/server/terminal_crosslink':
+:_os/src/server/terminal_crosslink/_:
   The terminal crosslink service allows to terminal clients to talk to each
   other.
 
-:'gems/src/server/http_block':
+:_gems/src/server/http_block/_:
   A block service that fetches a virtual block device over the network from
   a HTTP server.
 
-:'os/src/server/fs_rom':
+:_os/src/server/fs_rom/_:
   A ROM service that translates the 'File_system' session interface to the
   'ROM' session' interface. Each request for a ROM file is handled by looking
   up an equally named file on the file system.
-  Please refer to 'os/src/server/fs_rom' for more information.
+  Please refer to _os/src/server/fs_rom/_ for more information.
 
   For use cases where ROMs are known to be static, the
-  'os/src/server/cached_fs_rom' can be considered as a faster alternative to
+  _os/src/server/cached_fs_rom/_ can be considered as a faster alternative to
   the regular 'fs_rom' server. Note that 'cached_fs_rom' is not supported
   in base-linux though.
 
-:'os/src/server/chroot':
+:_os/src/server/chroot/_:
   An intermediate file-system server that makes a sub directory of a file
   system available as the root of a file system handed out to its client.
 
-:'os/src/server/dynamic_rom':
+:_os/src/server/dynamic_rom/_:
   A simple ROM service that provides ROM modules that change in time according
   to a configured timeline.
 
-:'os/src/server/report_rom':
+:_os/src/server/report_rom/_:
   A service that implements both the report session interface and the ROM
   session interface. It reflects incoming reports as ROM modules.
 
-:'os/src/server/fs_report':
+:_os/src/server/fs_report/_:
   Report server that writes reports to file-systems
 
-:'os/src/server/clipboard':
+:_os/src/server/clipboard/_:
   This component is both a report service and a ROM service. The
   clients of the report service can issue new clipboard content, which
   is then propagated to the clients of the ROM service according to a
   configurable information-flow policy.
 
-:'os/src/server/event_filter':
+:_os/src/server/event_filter/_:
   A component that transforms and merges input events from multiple sources
   into a single event stream.
 
-:'libports/src/app/acpi_event':
+:_libports/src/app/acpi_event/_:
   A component that transforms ACPI events into Genode input events.
 
-:'gems/src/server/gui_fader':
+:_gems/src/server/gui_fader/_:
   A wrapper for nitpicker's GUI session interface that applies alpha-blending
   to the of views a GUI client.
 
@@ -461,37 +459,37 @@ implement the VFS-plugin interface. They can be combined with any application
 based on Genode's C runtime, with the VFS server, and with non-POSIX
 components that use the Genode's VFS library directly.
 
-:'gems/src/lib/vfs/trace':
+:_gems/src/lib/vfs/trace/_:
   A VFS plugin that makes core's TRACE service accessible as a pseudo
   file system.
 
-:'gems/src/lib/vfs/import':
+:_gems/src/lib/vfs/import/_:
   A VFS plugin that pre-populates a VFS with initial content.
 
-:'gems/src/lib/vfs/pipe':
+:_gems/src/lib/vfs/pipe/_:
   A VFS plugin that provides bi-directional pipes for exchanging streamed
   data between components.
 
-:'gems/src/lib/vfs/ttf':
+:_gems/src/lib/vfs/ttf/_:
   A VFS plugin that makes rendered pixel data of the glyphs of Truetype fonts
   available as a pseudo file system.
 
-:'libports/src/lib/vfs/jitterentropy':
+:_libports/src/lib/vfs/jitterentropy/_:
   A VFS plugin that provides random numbers based on the jitter of executing
   CPU instructions.
 
-:'libports/src/lib/vfs/lwip':
+:_libports/src/lib/vfs/lwip/_:
   A VFS plugin that uses the light-weight IP (lwIP) stack to provide a
   network socket interface as a pseudo file system.
 
-:'dde_linux/src/lib/vfs/lxip':
+:_dde_linux/src/lib/vfs/lxip/_:
   A VFS plugin that uses the TCP/IP stack ported from the Linux kernel to
   provide a network socket interface as a pseudo file system.
 
-:'libports/src/lib/vfs/fatfs':
+:_libports/src/lib/vfs/fatfs/_:
   A VFS plugin that allows for the mounting of FAT-formatted block devices.
 
-:'dde_rump/src/lib/vfs/rump':
+:_dde_rump/src/lib/vfs/rump/_:
   A VFS plugin that enables the use of NetBSD's file-system drivers such
   as ext2 or msdos.
 
@@ -499,41 +497,41 @@ components that use the Genode's VFS library directly.
 Libraries
 =========
 
-:'libports/lib/mk/libc':
+:_libports/lib/mk/libc/_:
   C runtime ported from FreeBSD.
 
-:'libports/lib/mk/stdcxx':
+:_libports/lib/mk/stdcxx/_:
   Standard C++ library
 
-:'libports/lib/mk/mesa_api':
+:_libports/lib/mk/mesa_api/_:
   Mesa OpenGL API with backends for software rasterization (egl_swrast)
   and Intel Graphics (egl_i965)
 
-:'libports/lib/mk/mupdf':
+:_libports/lib/mk/mupdf/_:
   PDF rendering engine.
 
-:'libports/lib/mk/ncurses':
+:_libports/lib/mk/ncurses/_:
   Library for implementing pseudo-graphical applications (i.e., VIM) that
   run on a text terminal.
 
-:'libports/lib/mk/qt5_*':
+:_libports/lib/mk/qt5_*/_:
   Qt5 framework, using GUI session and NIC session as back end.
 
-:'libports/lib/mk/vfs_jitterentropy.mk':
+:_libports/lib/mk/vfs_jitterentropy.mk_:
   A VFS plugin that makes a jitter-based random-number generator available
   as a file within the process-local VFS.
 
-:'libports/lib/mk/libarchive.mk':
+:_libports/lib/mk/libarchive.mk_:
   Library providing a common interface to a variety of archive
   formats.
 
-:'libports/lib/mk/lz4.mk':
+:_libports/lib/mk/lz4.mk_:
   Library for processing LZ4 lossless compression archives.
 
-:'libports/lib/mk/liblzma.mk':
+:_libports/lib/mk/liblzma.mk_:
   Library for processing LZMA archives.
 
-:'libports/lib/mk/libgcrypt.mk':
+:_libports/lib/mk/libgcrypt.mk_:
   GnuPG library for OpenPGP processing, e.g., signature verification.
 
 
@@ -541,100 +539,96 @@ Applications
 ############
 
 Applications are Genode components that use other component's services but
-usually do not provide services. They are typically located in the 'src/app/'
+usually do not provide services. They are typically located in the _src/app/_
 subdirectory of a repository. Most applications come with README files
 located in their respective directory.
 
-:'gems/src/app/backdrop':
+:_gems/src/app/backdrop/_:
   GUI client application that sets a composition of PNG images as desktop
   background.
 
-:'demo/src/app/launchpad':
+:_demo/src/app/launchpad/_:
   Graphical application for interactively starting and killing subsystems.
 
-:'gems/app/launcher': Graphical launcher of Genode subsystems.
-
-:'demo/src/app/scout':
+:_demo/src/app/scout/_:
   Graphical hypertext browser used for Genode's default demonstration scenario.
 
-:'libports/src/test/mesa_demo':
-  Example programs for using the Mesa OpenGL graphics stack.
-
-:'ports/src/app/arora':
-  Arora is a Qt-based web browser using the Webkit engine.
-
-:'ports/src/app/gdb_monitor':
+:_ports/src/app/gdb_monitor/_:
   Application that allows the debugging of a process via GDB over a remote
   connection.
 
-:'libports/src/app/qt5/qt_launchpad':
+:_libports/src/app/qt5/qt_launchpad/_:
   Graphical application starter implemented using Qt.
 
-:'libports/src/app/qt5/examples/':
+:_libports/src/app/qt5/examples/_:
   Several example applications that come with Qt.
 
-:'os/src/app/sequence':
+:_os/src/app/sequence/_:
   Simple utility to serialize the execution of multiple components
 
-:'ports/src/noux-pkg':
+:_ports/src/noux-pkg/_:
   Ports of popular commandline-based Unix software such as VIM, bash,
   coreutils, binutils, gcc, findutils, and netcat. The programs are supposed
   to be executed within the Noux runtime environment.
 
-:'ports/src/app/lighttpd':
+:_ports/src/app/lighttpd/_:
   Lighttpd is a fast and feature-rich web server. The port of lighttpd uses
   a file-system session to access the website content and the web-server
   configuration.
 
-:'os/src/app/trace_logger':
+:_os/src/app/trace_logger/_:
   Convenient, runtime-configurable frontend to the tracing facility.
 
-:'os/src/app/rom_reporter':
+:_os/src/app/rom_reporter/_:
   The ROM-reporter component requests a ROM session and reports the
   content of the ROM dataspace to a report session with the same label
   as the ROM session.
 
-:'os/src/app/log_core':
+:_os/src/app/log_core/_:
   Component transforming core and kernel output to Genode LOG output.
 
 
 Package-management components
 =============================
 
-:'gems/src/app/depot_query':
+:_gems/src/app/depot_query/_:
   Tool for querying subsystem information from a depot.
 
-:'gems/src/app/depot_download_manager':
+:_gems/src/app/depot_download_manager/_:
   Tool for managing the download of depot content.
 
-:'gems/src/app/depot_deploy':
+:_gems/src/app/depot_deploy/_:
   Subsystem init configuration generator based on blueprints.
 
-:'libports/src/app/fetchurl':
+:_libports/src/app/fetchurl/_:
   A runtime-configurable frontend to the libcURL library for
   downloading content.
 
-:'libports/src/app/extract':
+:_libports/src/app/extract/_:
   Tool for extracting archives using libarchive.
 
-:'ports/src/app/verify':
+:_ports/src/app/verify/_:
   This component verifies detached OpenPGP signatures using libgcrypt.
 
 
 Runtime environments
 ####################
 
-:'ports/src/app/seoul': Seoul is a virtual-machine monitor developed for
+:_ports/src/app/seoul/_: Seoul is a virtual-machine monitor developed for
   the use with the NOVA platform. It virtualizes 32bit x86 PC hardware
   including various peripherals.
 
-:'os/src/server/loader': A service that allows the creation and destruction
+:_os/src/server/loader/_: A service that allows the creation and destruction
   of Genode subsystems via a session interface. For further information,
-  refer to 'os/src/server/loader/README'.
+  refer to _os/src/server/loader/README_.
 
-:'ports/src/virtualbox': VirtualBox running on top of the NOVA hypervisor.
+:_ports/src/virtualbox5/_: VirtualBox running on top of the NOVA hypervisor.
 
-:'os/src/server/vmm': A virtual machine monitor that is based on
+:_os/src/server/vmm/_: A virtual machine monitor that is based on
   hardware-assisted virtualization of ARM platforms. It is supported on
   the base-hw kernel only.
 
+:_os/src/server/cpu_balancer/_: The CPU balancer intercepts the interaction
+  of components with core's low-level services to migrate threads dynamically
+  between CPU cores.
+

doc/news.txt

@@ -4,6 +4,148 @@
                                ===========
 
 
+Sculpt OS release 21.03 | 2021-03-24
+####################################
+
+| Version 21.03 of the Sculpt operating system makes the system resilient
+| against classes of driver failures, adds configurable real-time priorities,
+| and introduces interfaces for screen capturing and user-event injection.
+
+Sculpt OS 21.03 incorporates the many improvements of the latest two Genode
+releases. Thanks to Genode's concept of
+[https://genode.org/documentation/release-notes/21.02#Pluggable_network_device_drivers - pluggable device drivers],
+the system has reached a new level of robustness against malfunctioning
+drivers. For example, if the Intel graphics driver trips over an unsupported
+external display, the driver gets automatically restarted while all graphical
+applications keep running. Or as another example, should the overly complex
+Wifi driver have a hick-up, it can be restarted with a simple mouse click
+without harming the networking stacks running on top.
+
+Even though Genode supports static-priority scheduling since more than a
+decade, Sculpt did not make this feature available to end users so far. The
+new version changes that. For each component, the user can now take a
+deliberate decision about the hard scheduling priority, e.g., prioritizing
+latency-critical multi-media applications over computational workloads or
+virtual machines.
+
+Speaking of workloads, to push the limits of what is possible with Sculpt OS,
+the new version introduces additional interfaces that can be assigned to
+components. First, it has become possible to redirect the interaction of a
+component with the kernel through another component, thereby enabling features
+like dynamic CPU-load balancing to be implemented as plain user-level
+services. Second, there are new interfaces for capturing the screen and for
+injecting input events. The latter interfaces pave the ground for virtual
+keyboards, screen-sharing application, or remote administration scenarios.
+
+Under the hood, there are plenty of improvements that make the life of
+Sculpt users better. The keyboard layout can now be picked from a menu.
+The Chromium-based Falkon web browser runs circles around the previous
+version. Menu items and file lists appear nicely sorted. Terminal windows
+immediately respond to global font-size changes. On modern Intel machines,
+Sculpt leverages Intel Hardware P-states (HWP) for power and thermal
+management now. You can find an illustrated tour of these and more changes in
+a dedicated
+[https://genodians.org/nfeske/2021-03-24-sculpt-os - article at Genodians.org].
+
+The updated [https://genode.org/documentation/articles/sculpt-21-03 - manual]
+goes into detail about the use of the new system.
+
+The ready-to-use system image for version 21.03 is available at the
+[https://genode.org/download/sculpt - Sculpt download page].
+
+
+Genode OS Framework release 21.02 | 2021-02-25
+##############################################
+
+| The highlights of version 21.02 are the addition of VirtualBox 6,
+| mobile-data connectivity via LTE, pluggable network drivers, initial
+| support for the Pine-A64-LTS board, and revived work on RISC-V.
+
+Many topics of the current release draw a connection to our overarching goal
+to use Genode on the Pinephone by the end of the year. Besides the obvious
+steps of enabling the hardware - starting with the Pine-A64-LTS board - the
+release introduces mobile-data connectivity as a Genode feature, and changes
+the network-driver architecture in anticipation of dynamic power-management
+schemes.
+
+For PC hardware, the flagship feature of version 21.02 is the addition of
+VirtualBox 6, giving us the prospect to eventually replace the aging port of
+VirtualBox 5. Speaking of VirtualBox, the release comes with profound
+improvements of the USB-device pass-through abilities, most importantly
+covering audio headsets.
+
+Besides these prominent features, the new version comes with many further
+improvements. Just to name a few, virtual machines on ARM have become
+able to provide VirtIO-block devices to guests, named pipes can now
+be used to connect components, Genode's RISC-V support received an
+update to ISA spec 1.10, and OpenSSL has been bumped to version 1.1.1.
+For the full story, please refer to the
+[https:/documentation/release-notes/21.02 - release documentation of version 21.02...]
+
+
+Road Map for 2021 | 2021-01-15
+##############################
+
+| In 2021, we plan to bring Genode to the Pinephone, advance the framework's
+| GPU support, and focus on development workflows.
+
+During the annual road-map discussion on Genode's public
+[https://genode.org/community/mailing-lists - mailing list],
+the following hot topics for this year emerged.
+
+First and most inspiring for many Genode developers, we aspire to have
+Genode running on the Pinephone with basic feature-phone functionality by the
+end of the year. Since this will involve substantial device-driver-related
+developments, the team will take this line of work as an opportunity to
+advance the tooling and workflows for carrying out such tasks. This, in turn,
+will hopefully ease the on-boarding of new driver developers in the future.
+
+Closely related to the Pinephone scenario, the project will make optimizations
+a top priority this year. The opportunities are plenty, ranging from
+micro-optimizations, over API refinements, to architectural changes if
+needed.
+
+Another recurring topic is the request for GPU support, which is required
+by many modern workloads such as video conferencing or streaming on mobile
+device. Therefore, we will revamp our past developments of GPU multiplexing
+on Intel hardware while also starting the investigation of GPUs on ARM-based
+devices.
+
+More information about our review of the past year, this year's focus, and a
+rough schedule are presented at our official
+[https:/about/road-map - road-map page].
+
+
+Genode OS Framework release 20.11 | 2020-11-27
+##############################################
+
+| Genode 20.11 brings Sculpt OS to 64-bit ARM hardware, introduces dynamic
+| CPU-load balancing, and enables multicore virtualization on ARM. Driver-wise,
+| the release improves audio on PC hardware, and adds VirtIO networking support.
+
+ARM 64-bit has been a recurring theme of the Genode releases this year and the
+just released version 20.11 is no exception. We are proud to announce that our
+Genode-based custom general-purpose OS called Sculpt has come to life on
+64-bit ARM hardware, namely the NXP i.MX8 EVK board. This is the result of
+intensive work on the framework's driver architecture for ARM and several
+SoC-specific device drivers. Closely related to this line of work is the new
+ability to run multicore virtual machines on ARM.
+
+Another highlight of version 20.11 is a new CPU balancing mechanism, which
+automates the dynamic assignment of threads to CPU cores for complex
+workloads. With traditional operating systems, such policies are normally part
+of the OS kernel. Thanks to Genode's component architecture, we are able to
+implement such potentially complex policies in the form of an optional
+component, which offers ultimate flexibility while keeping the kernel
+untainted by complex heuristics.
+
+Further topics of the current release are improved power management and audio
+support on PC hardware, a new OSS API emulation that allows for the
+reuse of popular audio applications on Genode, and new support for VirtIO
+networking. The full picture is given by the
+[https:/documentation/release-notes/20.11 - release documentation of version 20.11...]
+
+
 Sculpt OS release 20.08 | 2020-09-17
 ####################################
 
@@ -181,7 +323,7 @@ please consult the
 Road Map for 2020 | 2020-01-20
 ##############################
 
-| In 2019, we will be concerned about dwarfing the barrier of entry into
+| In 2020, we will be concerned about dwarfing the barrier of entry into
 | the Genode world.
 
 Following the last year's leitmotif of "bridging worlds", we turn our
@@ -2924,7 +3066,7 @@ applications, most prominently, it serves as the foundation of the KDE project.
 Since the release 9.05, the official distribution of Genode supports Qt4 as a
 regular feature. The document "Portierung von Qt auf Genode" _(german)_
 describes the challenging endeavor of porting this high-complexity C++
-framework to Genode. Major problems to overcome had been the missing C libary
+framework to Genode. Major problems to overcome had been the missing C library
 (at the time when the project started), the integration of the Qt4 project
 files with Genode's build system, the adaption of Qt4 to the basic primitives
 provided by Genode, and the integration of Qt4 with Genode's GUI. In addition

doc/release_notes/20-08.txt

@@ -34,10 +34,10 @@ like swapping out or updating drivers on the fly without reboot.
 Besides these main topics, the current release features the continuation of of
 two long-term projects, namely the CBE block encrypter and the profound
 support of 64-bit ARM devices.
-Section [Consistent Block Encrypter] describes the CBE's new *pluggable
-crypto* and trust anchor facilities.
-Section [Device drivers] goes into detail about the steadily emerging *driver
-landscape on 64-bit ARM*.
+Section [Consistent Block Encrypter] describes the CBE's new *pluggable crypto*
+and trust anchor facilities.
+Section [Device drivers] goes into detail about the steadily
+emerging *driver landscape on 64-bit ARM*.
 
 
 The GUI stack, restacked
@@ -423,8 +423,8 @@ C runtime
 Serialized VFS access
 ~~~~~~~~~~~~~~~~~~~~~
 
-Unsurprisingly, the VFS is an integral part of the C runtime as _everything is
-a file_ in the UNIX philosophy. The basis for the libc VFS is the VFS library
+Unsurprisingly, the VFS is an integral part of the C runtime as _everything is_
+_a file_ in the UNIX philosophy. The basis for the libc VFS is the VFS library
 and its versatile plugin concept. As the libc (and other users of the library)
 may employ multiple threads, which could use the VFS, the integrity of data
 structures, esp. those of more complex plugins like the network stack in

doc/release_notes/20-11.txt

@@ -0,0 +1,629 @@
+
+
+              ===============================================
+              Release notes for the Genode OS Framework 20.11
+              ===============================================
+
+                               Genode Labs
+
+
+
+With Genode 20.11, we focused on the scalability of real-world application
+workloads, and nurtured Genode's support for 64-bit ARM hardware. We thereby
+follow the overarching goal to run highly sophisticated Genode-based systems
+on devices of various form factors.
+
+When speaking of real-world workloads, we acknowledge that we cannot always
+know the exact behavior of applications. The system must deal gracefully with
+many unknowns: The roles and CPU intensity of threads, the interplay of
+application code with I/O, memory-pressure situations, or the sudden fragility
+of otherwise very useful code. The worst case must always be anticipated. In
+traditional operating systems, this implies that the OS kernel needs to be
+aware of certain behavioral patterns of the applications, and has to take
+decisions based on heuristics. Think of CPU scheduling, load balancing among
+CPU cores, driving power-saving features of the hardware, memory swapping,
+caching, and responding to near-fatal situations like OOM.
+
+Genode allows us to move such complex heuristics outside the kernel into
+dedicated components. Our new CPU balancer described in Section
+[CPU-load balancing] is a living poster child of our approach. With this
+optional component, a part of a Genode system can be subjected to a CPU-load
+balancing policy of arbitrary complexity without affecting the quality of
+service of unrelated components, and without polluting the OS kernel with
+complexity.
+
+A second aspect of real-world workloads is that they are usually *not*
+designed for Genode. To accommodate the wealth of time tested applications, we
+need to bridge the massive gap between APIs of olde (think of POSIX) and
+Genode's clean-slate interfaces.
+Section [Streamlined ioctl handling in the C runtime / VFS] shows how the
+current release leverages our novel VFS concept for the emulation of
+traditional ioctl-based interfaces. So useful existing applications come to
+live without compromising the architectural benefits of Genode.
+
+Platform-wise, the new release continues our mission to host Genode-based
+systems such as [https://genode.org/download/sculpt - Sculpt OS] on 64-bit
+ARM hardware. This work entails intensive development of device drivers and
+the overall driver architecture.
+Section [Sculpt OS on 64-bit ARM hardware (i.MX8 EVK)] reports on the
+achievement of bringing Sculpt to 64-bit i.MX8 hardware. This line of work
+goes almost hand in hand with the improvements of our custom virtual machine
+monitor for ARM as outlined in Section [Multicore virtualization on ARM].
+
+
+CPU-load balancing
+##################
+
+Migrating load over CPUs may be desirable in dynamic scenarios, where the
+workload is not known in advance or too complex. For example, in case of POSIX
+software ported to Genode, amount and roles of threads and processes can
+generally not planned for. With the current release, we add an optional CPU
+service designated for such dynamic scenarios. The new component called
+[https://genodians.org/alex-ab/2020-11-16-cpu-balancer - CPU balancer] is able
+to monitor threads and their utilization behaviour. Depending on configured
+policies, the balancer can instruct Genode's core via the CPU session
+interface to migrate threads between CPUs.
+
+[image cpu_balancer]
+  The CPU balancer intercepts the interaction of a Genode subsystem
+  (workload) with core's low-level CPU service.
+
+This feature requires a kernel that supports thread migration, which are
+Fiasco.OC, seL4, and to some degree the NOVA kernel. For the NOVA kernel,
+solely threads with an attached scheduling context can be migrated, which are
+'Genode::Thread' and POSIX pthread instances. Genode's entrypoint and virtual
+CPU instances are not supported.
+
+The feature can be tested by the scenario located at _repos/os/run/cpu_balancer.run_.
+Further information regarding policy configuration, a demo integration into
+Sculpt 20.08, and a screencast video are available as a dedicated
+[https://genodians.org/alex-ab/2020-11-16-cpu-balancer - CPU balancer]
+article.
+
+
+Sculpt OS on 64-bit ARM hardware (i.MX8 EVK)
+############################################
+
+Within the last year, a lot of effort was put into Genode's support for ARM
+64-bit hardware. A consequent next step was to port Sculpt OS to the i.MX8 EVK
+board, which we have used so far as reference platform. With the current
+release, we proudly present the first incarnation of Sculpt OS for this board.
+
+In contrast to the original x86 PC variant, this first ARM version ships with
+a static set of devices inside the drivers subsystem. No device manager
+component probes for the used hardware and starts drivers on demand. Instead,
+the set of drivers defined in the _drivers_managed-imx8q_evk_ package enables
+USB HID devices to make use of mouse and keyboard peripherals connected to the
+board. It drives the SD-card, which can be used as storage back end for
+Genode's depot package management. Finally, it contains drivers to manage the
+display engine and the platform's device resources.
+
+With Sculpt OS for ARM 64-bit, we not only aim for classical desktop/notebook
+systems - like on x86 - but also for embedded consumer hardware like phones
+and tablets. In order to leverage this goal, we enabled support for
+[https://www.nxp.com/design/development-boards/i-mx-evaluation-and-development-boards/i-mx-8-series-accessory-boards:i.MX8-ACCESSORY-BOARDS - NXP's MX8_DSI_OLED1]
+display on the i.MX8 platform on Genode. The panel features an OLED display as
+well as a Synaptics RMI4 compliant touch screen.
+
+Genode's i.MX8 display driver that we released with version
+[https://genode.org/documentation/release-notes/20.02#Display_engine - 20.02]
+supported HDMI devices only, whereas the OLED display is connected via
+[https://www.mipi.org/specifications/dsi - MIPI DSI] to the SoC. Therefore, we
+extended the display driver by the MIPI DSI infrastructure as well as the
+actual driver for the OLED display. This endeavor turned out to be a very
+rocky one, which we have documented in detail on our
+[https://genodians.org/ssumpf/2020-09-30-mipi_touch - Genodians] website.
+
+[image imx8_oled]
+  The administrative user interface of Sculpt OS responds to touch input.
+
+In order to enable the touch screen device, we implemented a new Genode
+component from scratch. The touch screen is connected via an I2C bus to the
+SoC where data can be sent to and received from. At the moment, the I2C
+implementation is hidden within the driver but as more devices require I2C
+access, it will eventually become a standalone component. Interrupts are
+delivered via GPIO pins from the touch screen to the SoC, which made it
+necessary to enable i.MX8 support within Genode's generic i.MX GPIO driver. We
+took this as an opportunity to streamline, cleanup, and make the driver more
+robust. Additionally, all driver components now take advantage of the new
+platform driver API for ARM that has been introduced with release
+[https://genode.org/documentation/release-notes/20.05#New_platform_driver_for_the_ARM_universe - 20.05].
+
+In its current incarnation, the driver for the display management is not able
+to switch in between HDMI or MIPI-DSI connected displays dynamically.
+Therefore, the display to be used in Sculpt has to be configured in the
+framebuffer configuration manually. By default the HDMI connector is used.
+
+Beyond the driver subsystem, there are few components dependent on the actual
+hardware, which is why the look & feel of the Sculpt desktop does not actually
+differ from the x86 PC version, with the following exceptions:
+
+When you select the network configuration dialog, you'll have no "Wifi" option
+because of the missing hardware. However, the "Wired" option allows you to
+start the corresponding driver for the i.MX FEC Ethernet device. The second
+difference to the Sculpt OS x86 PC variant is the absence of a virtual machine
+solution at the moment. Although Genode comprises a mature
+virtual-machine-monitor solution for ARM - see
+Section [Multicore virtualization on ARM] - it still lacks a reasonable
+storage back end. Therefore, we left virtualization out of the picture for
+now. Lastly, there is no possibility to use USB block devices, because the
+required management component - a driver manager for i.MX8 - does not exist
+yet. We plan to bridge these remaining few gaps compared to the x86 version
+with the upcoming Genode releases.
+
+To give Sculpt a try on the i.MX8 EVK board, you have to start the well-known
+Sculpt run-script as usual, but for the base-hw kernel. For example:
+
+!  tool/create_builddir arm_v8a
+!  cd build/arm_v8a
+!  make run/sculpt KERNEL=hw BOARD=imx8q_evk
+
+Under the hood, the run script requests a sculpt-<board> specific package from
+the depot package system. Currently, _sculpt-pc_ and _sculpt-imx8q_evk_ are
+available.
+
+
+Multicore virtualization on ARM
+###############################
+
+The written-from-scratch virtualization solution for Genode on ARMv8 entered the
+picture exactly one year ago with
+[https://genode.org/documentation/release-notes/19.11#Virtualization_of_64-bit_ARM_platforms - release 19.11].
+Since then, a couple of improvements and validations have been incorporated
+into it. Support for VirtIO network and console models had been added.
+Moreover, it got streamlined with our prior existing ARMv7 hypervisor and
+virtual-machine monitor (VMM). But although the architecture of the VMM was
+designed from the very beginning with more than one virtual-CPU (VCPU) in
+mind, running a VM on multiple cores had not been addressed nor tested.
+
+With this release, we enhance the virtualization support of the base-hw
+kernel, acting as the ARM hypervisor, to support multicore virtual machines.
+The VMM implementation got extended to start an entrypoint for each VCPU owned
+by a VM. The affinities of those entrypoints are configured to distribute over
+all physical CPUs available to the VMM. The affinity of an entrypoint that
+handles events of a VCPU is automatically used as the affinity of the VCPU
+itself. Whenever a VCPU exit needs to be handled, this is delegated to the VMM
+entrypoint running on the same CPU. Once the VMM's entrypoint successfully
+handled the exit reason, it resumes the VCPU.
+
+Formerly, the control to start or stop a VCPU was implemented by core's VM
+service that runs on the first CPU. But that implied that all different VMM
+entrypoints running on distinct CPUs would have needed to frequently call
+core's service entrypoint on the first CPU, inducing costly cross-CPU
+communication. This is amplified by the fact that core's entrypoint uses a
+system call to instruct the kernel's internal scheduler of the corresponding
+target CPU, which again would potentially target a remote CPU. For simplifying
+the implementation and for improving performance, we slightly extended the
+VM-session interface to return a kernel-specific capability addressing a VCPU
+directly. With this capability, a VMM's entrypoint is able to directly call
+the kernel to start or stop a VCPU instead of using the indirection over core.
+However, the detail whether the kernel is called directly or not is hidden
+behind the VM session client API and transparent to the user.
+
+
+Base framework and OS-level infrastructure
+##########################################
+
+C runtime
+=========
+
+We improved the support for aligned memory allocations to fix sporadic memory
+leaks, which occurred with our port of the Falkon web browser. One relevant
+change is the implementation of the 'posix_memalign()' function, another
+change is that the address alignment of anonymous 'mmap()' allocations is now
+configurable like follows:
+
+! <config>
+!     <libc>
+!         <mmap align_log2="21"/>
+!     </libc>
+! </config>
+
+
+Standard C++ library
+====================
+
+Even though Genode uses C++ as its primary programming language, we do not
+rely on or make use of any C++ standard library within the Genode OS
+framework. However, since a C++ STL is a vital part of application programming
+with C++, we provide one for applications built on top of the base framework;
+in particular the GNU C++ STL library (_libstdc++_). It is treated as a
+regular 3rd party library and its functionality is extended on demand. This
+approach worked well enough to even enable larger C++-based software like Qt5
+and Chromium's Blink engine (as part of QtWebEngine) to run on Genode. That
+being said, for developers using _libstdc++_ on Genode, it is not immediately
+clear, which features are supported and which are not.
+
+Fortunately, _libstdc++_ includes a testsuite that - as the name suggests -
+allows for testing the range of functionality of the library on a given
+platform. So we turned to it to establish a base line of supported features.
+We were particularly interested in how our port behaves when C++17 is
+requested. It goes without saying that this only includes the aspects, which
+are specifically probed by the testsuite. Rather than adding thorough Genode
+support to the testsuite, we opted for providing an
+[https://github.com/cnuke/genode-libstdcxx-testsuite/ - environment] that
+mimics the common 'unix' target and allows us to execute the testsuite on
+the Linux version of Genode via a regular Linux host OS. It uses the Genode
+tool chain to compile the tests and spawns a Genode base-linux system to
+execute them.
+
+Executing the testsuite was an iterative process because in the beginning, we
+encountered many falsely failed tests. On one hand, most of them were due to
+the way C++ is applied in Genode or rather how our build system works
+internally. For one, _libsupc++_ on Genode is part of the _cxx_ library. This
+library in turn is part of _ldso.lib.so_, the dynamic linker that provides
+the base API. As the build system uses stub libraries generated from 'symbol'
+files containing the ABI of a given shared object, each missing symbol must
+be made available. Otherwise the linking step is going to fail complaining
+about undefined references because components use these stub libraries
+during compilation. On the other hand, we had to get cozy with the testsuite's
+underlying test framework in order to get our test environment straight.
+
+In case of the testsuite, there were a lot of symbols missing because we did
+not encounter them so far in our workloads, and thus, were not part of the
+symbols file. After all, templates will always generate specific symbols that
+are difficult to foresee. Besides that, we lacked support for aligned 'new'
+and 'delete' operators. With these adaptions in place, we were able to
+successfully execute the testsuite.
+
+In the end, the results paint a good picture. The current short-comings boil
+down to
+
+* Support for the *stdc++fs* library is not available as the library is
+  not ported yet.
+* Proper *locale* support in the 'libc' as well as 'stdc++' is not available.
+* Support for parallel operations with *openmp* is not available.
+* Various subsystems ('std::thread', 'std::random_device', numerics library)
+  need further attention for proper functionality. This is most prominent
+  for the failing execution tests where sometimes the threads appear to
+  get stuck.
+
+These findings are documented at issue
+[https://github.com/genodelabs/genode/issues/3925 - 3925].
+
+
+Consistent Block Encrypter (CBE)
+================================
+
+The CBE is a library for the management of encrypted block-devices that is
+entirely written in SPARK. It was first announced and integrated with
+[https://genode.org/documentation/release-notes/19.11#Preliminary_block-device_encrypter - Genode 19.11],
+reached feature-completeness with
+[https://genode.org/documentation/release-notes/20.05#Feature-completeness_of_the_consistent_block_encrypter - Genode 20.05],
+and has received a highly modular back-end system with version
+[https://genode.org/documentation/release-notes/20.08#Consistent_Block_Encrypter - 20.08].
+For this release, we thoroughly streamlined the CBE repository, added enhanced
+automated quality assurance, and switched to another default encryption
+back end.
+
+
+Repository restructuring
+------------------------
+
+Generally speaking, the [https://github.com/m-stein/cbe - CBE repository] has
+been freed from everything that is not either part of the SPARK-based core
+logic (cbe, cbe_common, and the hashing algorithm), the essential SPARK-based
+tooling (initialization, checking), or the Ada-based C++ bindings (*_cxx
+libraries). The whole Genode-specific integration, testing, and packaging
+moved to Genode's 'gems' repository and the former Genode sub-repository 'cbe'
+was replaced by the new CBE port _gems/ports/cbe.port_. We also took the
+opportunity to remove many unused remnants of earlier development stages and
+to drastically simplify the ecosystem of CBE-related packages.
+
+We hope that this allows for certain characteristics of the CBE project, like
+its strong OS-independence or a completely "flow-mode"-provable core logic to
+become more clear, while at the same time, the Genode-specific accessories can
+benefit from being part of Genode's mainline development.
+
+
+Automated testing, benchmarking, and proving
+--------------------------------------------
+
+The CBE tester is a scriptable environment meant for testing all aspects of
+the CBE library and its basic tooling. Through its XML command interface, one
+can not only access and validate data of CBE devices but also initialize them,
+check their consistency, analyze their meta data, execute performance
+benchmarks, manage device snapshots, perform online re-keying or online
+re-dimensioning of devices, and, last but not least, manage the required Trust
+Anchors.
+
+Before this release, the CBE tester was a mere patchwork solution and many of
+the above mentioned features were limited or even missing. For instance block
+access was issued only in a synchronous fashion, the Trust-Anchor was managed
+implicitly, and validating read data wasn't possible. Besides adding the
+missing features, we also reworked the component entirely to follow a clean
+and comprehensible implementation concept. The new CBE tester comes together
+with the run script _gems/run/cbe_tester.run_ that shall serve as both a
+demonstration how to use the tester and an extensive automated test and
+benchmark for the CBE.
+
+Furthermore, we created the CBE-specific autopilot tool _tool/cbe_autopilot_
+that is meant to establish a common reference for the quality of CBE releases
+as well as for their integration in Genode. Running the tool without arguments
+will give instructions how to use it. In a nutshell, when running
+'tool/cbe_autopilot basics', the tool will GNAT-prove what is expected to be
+provable, run all CBE-related run scripts expected to work, and build all
+CBE-related packages (existing build and depot directories are not touched in
+this process). The idea is to make the successful execution of the test
+mandatory before advancing the master branch of the CBE repository or
+releasing a new version of the integration in Genode. A handy side-feature of
+the tool is that one can run 'tool/cbe_autopilot prove' to do only the
+GNAT-proving part. With 'tool/cbe_autopilot clean' finally, the tool cleans up
+all of its artifacts.
+
+
+Libcrypto back end for block encryption
+---------------------------------------
+
+The introduction of VFS plugins for CBE back ends in the previous Genode
+release made it much easier to interchange concrete implementations. This
+motivated us to play around a bit in our endeavour of optimizing execution
+time. It turned out that especially the choice of the block-encryption back
+end has a significant impact on the overall performance of CBE block
+operations. It furthermore seemed that especially the 'libsparkcrypto'
+library, our former default for block encryption, prioritizes other qualities
+over performance.
+
+That said, in general, we want to enable an informed user to decide for him-
+or herself which qualities one prefers in such an algorithm. The VFS plugin
+mechanism pays tribute to this. And it also seems very natural to us to
+combine a SPARK-based block-device management with a SPARK-based encryption
+back-end like 'libsparkcrypto'. But for our default use case, we came to the
+conclusion that the 'libcrypto' library might be a better choice.
+
+
+Streamlined ioctl handling in the C runtime / VFS
+=================================================
+
+The Genode release
+[https://genode.org/documentation/release-notes/19.11#C_runtime_with_improved_POSIX_compatibility - 19.11]
+introduced the emulation of ioctl operations via pseudo files. This feature
+was first used by the Terminal. With the current release, we further employ
+this mechanism for additional ioctl operations, like the block-device related
+I/O controls, as the long-term plan is to remove the notion of ioctl's from
+the 'Vfs::File_io_services' API all-together.
+
+We therefore equipped the block VFS-plugin with a compound directory hosting
+the pseudo files for triggering device operations:
+
+:info: This file contains the device information structured as 'block'
+  XML node having 'size' and 'count' attributes providing the used block size
+  as well as the total number of blocks.
+
+:block_count: contains the total number of blocks.
+
+:block_size: contains the size of one block in bytes.
+
+Furthermore, we split the existing 'ioctl' handling method in the libc into
+specific ones for dealing with terminals and block devices because at some
+point more different groups of I/O controls are to follow.
+
+The first one to follow is the 'SNDCTL' group. This group deals with audio
+devices and corresponds to the standard set by the OpenSoundSystem (OSS)
+specification years ago. In the same vein as the terminal and block I/O
+controls, the sound controls are implemented via property files.
+
+The controls currently implemented are the ones used by the OSS-output plugin
+of [https://cmus.github.io/ - cmus], the driving factor behind the
+implementation, which uses the (obsolete) version 3 API.
+
+At the moment, it is not possible to set or rather change any parameters. In
+case the requested setting differs from the parameters of the underlying
+audio-out session - in contrast to the suggestion in the OSS manual - we do
+not silently adjust the parameters returned to the callee but let the I/O
+control operation fail.
+
+The following list contains the currently handled SNDCTL I/O controls:
+
+:SNDCTL_DSP_CHANNELS: sets the number of channels. We return the available
+  channels here and return ENOTSUP if it differs from the requested number of
+  channels.
+
+:SNDCTL_DSP_GETOSPACE: returns the amount of playback data that can be written
+  without blocking. For now it amounts the space left in the stream buffer of
+  the audio-out session.
+
+:SNDCTL_DSP_POST: forces playback to start. We do nothing and return success.
+
+:SNDCTL_DSP_RESET: is supposed to reset the device when it is active before
+  any parameters are changed. We do nothing and return success.
+
+:SNDCTL_DSP_SAMPLESIZE: sets the sample size. We return the sample size of the
+  underlying audio-out session and return ENOTSUP if it differs from the
+  requested format.
+
+:SNDCTL_DSP_SETFRAGMENT: sets the buffer size hint. We ignore the hint and
+  return success.
+
+:SNDCTL_DSP_SPEED: sets the sample rate. For now, we always return the rate of
+  the underlying audio out session and return ENOTSUP if it differs from the
+  requested one.
+
+The libc extension is accompanied by an OSS VFS plugin that gives access to an
+audio-out session by roughly implementing an OSS pseudo-device. It merely
+wraps the session and does not provide any form of resampling or re-coding of
+the audio stream.
+
+[image cmus]
+
+Image [cmus] depicts how the various pieces work together in a real-world
+scenario. The interplay of the extended libc with the OSS VFS plugin allows
+for listening to MP3s - for the time being the format is restricted to
+44.1kHz/16bit - on Sculpt using the [https://cmus.github.io/ - cmus]
+audio player.
+
+The current state serves as a starting point for further implementing the OSS
+API to cover more use cases, especially with ported POSIX software like
+VirtualBox and Qt5 or even as SDL2 audio back end. While showing its age, OSS
+is still supported by the majority of middle ware and makes for a decent
+experimentation target.
+
+
+Device drivers
+##############
+
+VirtIO support
+==============
+
+Thanks to the remarkable contribution by Piotr Tworek, the Genode OS framework
+has become able to drive VirtIO network devices.
+
+He did not only provide a single VirtIO network driver but a framework to
+easily add more VirtIO driver classes in the future. Either the devices are
+connected as PCI devices or directly as platform devices with fixed
+memory-mapped I/O addresses. The framework supports both and abstracts away
+from the concrete connection type.
+
+The VirtIO network driver enables networking for Genode when using the
+'virt_qemu' board on either the ARMv7a or ARMv8a architecture. However, the
+VirtIO device configuration on Qemu is dynamic. The order and presence of
+different command line switches affect the bus address and interrupt
+assignment of each device. To make the use of Genode with Qemu robust in
+changing environments, a tiny helper component was supplemented. This
+component named 'virtdev_rom' probes the memory-mapped I/O areas of the system
+bus and detects available and known VirtIO devices. The results are provided
+in the form of a configuration that can be consumed by the platform driver to
+assign the correct device resources to the corresponding VirtIO driver.
+
+The VirtIO network driver in action, as well as the interplay of the platform
+driver and the 'virtdev_rom' component can be observed when using the
+'drivers_nic-virt_qemu' package.
+
+
+Improved support for OpenBSD audio drivers
+==========================================
+
+So far, the supported drivers exclusively used PCI as transport bus and for
+practical reasons, the emulation environment was tied to it. The bus handling
+has now moved into its own compilation unit to make future addition of drivers
+that employ other transport buses easier. On the same account, the component
+got renamed to 'pci_audio_drv' to reflect its bus connection.
+
+While at it, the execution flow of the component got adapted. The kernel code
+should have been executed within the context of the main task like it is done
+in the DDE Linux drivers. The initial port of the HDA driver, however, called
+the code directly from within the session as there was no immediate reason to
+use a task context because suspending the execution was not needed. When using
+USB devices, that is no longer possible as we have to suspend the execution
+during the execution of the kernel code. So we pass in the audio data and
+schedule the emulated BSD kernel code.
+
+The above mentioned changes are mostly preliminary clean-up work for the
+upcoming support of USB audio devices.
+
+Furthermore, we implemented timeout handling in the driver and use Genode's
+timeout framework API to schedule timeouts and for providing the current time.
+For now there is only one timeout - the unsolicited Azalia codec event - and
+therefore the timeout queue consists of solely one timeout object. Those
+events are important for detecting plugged in headphones.
+
+Supporting headphones was further refined by accounting for the situation
+where the driver is started while headphones are already plugged in and the
+mixer needs to be configured accordingly. In particular, on the Fujitsu S938
+the driver lacked the proper quirk for switching between the internal and
+external microphone.
+
+In addition to the changes made to the audio driver component, the behaviour
+of the audio mixer was adjusted with regard to handling the configuration
+of a new session. The mixer now applies the settings already stored in its
+configuration to new sessions instead of only reporting them. In case of
+Sculpt, where an existing launcher already contains a valid configuration,
+that allows for setting the volume levels appropriately for known sessions
+prior to establishing the connection.
+
+
+Retiring the monolithic USB driver
+==================================
+
+With [https://genode.org/documentation/release-notes/18.08#Decomposed_USB_stack - release 18.08],
+a componentized USB stack got introduced next to our time-tested monolithic
+USB driver. With the current release, the driver manager as used by Sculpt OS
+switched to use the new USB stack in order to benefit from the de-composition
+and from more supported USB devices. The monolithic driver was still based on
+an older DDE-Linux revision compared to the componentized version. This step
+paves the ground to retire the monolithic USB driver with the next Genode
+release and will improve the number of supported USB devices with the upcoming
+Sculpt OS release.
+
+
+Platforms
+#########
+
+Hardware P-State support on PC hardware
+=======================================
+
+Intel CPUs feature Speed Shift respectively Hardware P-State (HWP)
+functionality in order to balance CPU frequency and voltage for performance
+and power efficiency. Up to now, the UEFI firmware of the notebooks we worked
+with selected or made an option selectable in the UEFI configuration to
+specify the desired behaviour, e.g. optimize for performance or power
+efficiency.
+
+With a recent Lenovo notebook, however, we faced the issue that either the fan
+would run for too long after some load and/or the performance of the CPUs
+regressed. Finding a well working sweet spot
+[https://github.com/genodelabs/genode/issues/3871 - seems hard].
+This experience prompted us to investigate how the Intel HWP feature can be
+set and configured. After some experiments, we achieved to reduce the fan
+noise and received better performance by tweaking the Intel HWP settings.
+
+However, changing the Intel HWP settings requires access to the privileged
+mode on all available CPUs. Since Genode supports several kernels, a solution
+would require us to modify all kernels or the feature would remain solely
+available to one kernel. We went for a different approach.
+
+On x86, we use the tools from the
+[https://genode.org/documentation/release-notes/18.08#New_Intel_Microcode_update_mechanism - Morbo project],
+e.g., bender and microcode, to run code before the kernels are booted. The
+jobs of the tools are to scan, enable, or apply changes to the CPUs and
+chipset, which are not required to change during runtime. We came to the
+conclusion that the named bootstrap tools are good places to apply such
+one-time Intel HWP settings for the moment.
+
+During the course of adding the Intel HWP functionality, we merged the
+microcode functionality into the bender tool and made it configurable via the
+boot options 'microcode' and 'intel_hwp'. A typical generated grub2
+configuration by using both options would look like this:
+
+| insmod multiboot2
+| insmod gzio
+| multiboot2 /boot/bender bender microcode intel_hwp
+| module2    /boot/micro.code micro.code
+| module2    /boot/hypervisor hypervisor ...
+| module2    /boot/image.elf.gz image.elf ...
+
+When using the NOVA kernel and Genode's _run_ tool for booting respectively
+disk-image creation, one may use the existing 'options_bender' variable in
+_tool/run/boot/nova_. The microcode option is added by setting the
+'apply_microcode' flag in the same file. The 'intel_hwp' option, at the other
+hand, can simply be appended to 'options_bender'. On startup, bender will print
+the applied HWP settings for each core to the serial output if the
+'intel_hwp' option was set. The new feature will try to set Intel HWP to
+'PERFORMANCE' mode, the mode for which we observed the best results.
+
+
+NOVA microhypervisor
+====================
+
+The IO-MMU is a hardware feature to protect operating systems, e.g., Genode,
+against misbehaving devices and/or corresponding device drivers. The feature
+is supported on x86 since the
+[https://genode.org/documentation/release-notes/13.02#DMA_protection_via_IOMMU - 13.02 release]
+and described in the release notes. Up to now, this feature is solely
+supported for Intel hardware, in particular CPUs and chipsets supporting Intel
+VT-d.
+
+With the current release, we add support for AMD's IO-MMU variant to the
+Genode framework for the NOVA kernel - being the first one out of the
+supported microkernels. Being conceptionally equivalent, the actual
+implementation for AMD differs from Intel unsurprisingly. In order to add the
+support, a new IO-MMU interface abstraction for accommodating both versions -
+Intel and AMD - has been added to the NOVA kernel. Further, the discovery of
+the available AMD IO-MMUs required the traversal of different ACPI tables than
+for Intel and another page table format for the IO-MMU had to be added. On the
+Genode framework side, only very few changes were necessary, namely the
+detection of the IO-MMU feature by parsing the ACPI tables in Genode's ACPI
+driver as well as the ported Intel ACPICA component.
+
+The change has been already successfully tested on various Ryzen desktops and
+notebooks on a backported Sculpt 20.08 branch.

doc/release_notes/21-02.txt

@@ -0,0 +1,663 @@
+
+
+              ===============================================
+              Release notes for the Genode OS Framework 21.02
+              ===============================================
+
+                               Genode Labs
+
+
+
+Genode 21.02 stays close to the plan laid out on our
+[https://genode.org/about/road-map - road map], featuring a healthy dose
+of optimizations, extends the framework's ARM SoC options, and introduces
+three longed-for new features.
+
+First, we extended our concept of pluggable device drivers to all network
+drivers, including Ethernet and Wifi.
+As reported in Section [Pluggable network device drivers], such drivers can
+now gracefully be started, restarted, removed, and updated at runtime without
+disrupting network-application stacks.
+
+Second, the release features the infrastructure needed for mobile-data
+communication over LTE, which is a prerequisite for our ambition to use Genode
+on the Pinephone. Section [LTE modem stack] gives insights into the involved
+components and the architecture.
+
+Third, we are happy to feature the initial version of VirtualBox 6 for
+Genode. Section [VirtualBox 6.1.14] gives an overview of the already
+supported feature set and the outlook to reach feature-parity to our version
+of VirtualBox 5 soon.
+Speaking of VirtualBox in general (both versions), we were able
+to significantly improve the USB-device pass-through abilities, specifically
+covering audio headsets.
+
+Further noteworthy improvements of the current release range from added
+VirtIO-block device support for virtual machines on ARM
+(Section [VirtIO block devices for virtual machines on ARM]),
+revived developments on RISC-V (Section [RISC-V]),
+over VFS support for named pipes (Section [VFS support for named pipes]),
+to streamlined tooling (Section [Build system and tools]).
+
+
+Pluggable network device drivers
+################################
+
+The results of our approach to
+[https://genode.org/documentation/release-notes/20.08#The_GUI_stack__restacked - pluggable framebuffer and input drivers]
+encouraged us to take on the third major driver category, namely networking
+drivers, which subsumes not only Ethernet drivers but also wireless networking
+drivers and mobile baseband drivers. The latter two are of course particularly
+interesting for mobile communication devices.
+
+Similarly to the story linked above for the framebuffer and input drivers,
+Genode's network drivers used to play the roles of NIC servers, providing a
+network-interface service to network applications. As a consequence, the
+lifetime of a network application was always bound to the lifetime of the
+underlying NIC driver. This is unfortunate because those drivers can be
+obscenely complex, putting the liveliness of the dependent application stack
+at risk.
+
+[image layered_nic_multi_app_risk]
+
+However, in most scenarios, networking applications do not operate directly on
+a network interface because this would prevent the use of the network interface
+by more than one application at a time. Instead, there is usually a NIC
+multiplexing component in-between the driver and one or multiple applications.
+In most contemporary scenarios this is the NIC router that acts as NIC client
+towards the driver and as NIC server towards the applications.
+
+Thus, we contemplated the idea of letting the NIC driver operate as NIC client
+of the NIC router instead. This would decouple the application from the
+driver's lifetime while the driver's special role would be modeled solely by a
+routing policy. However, even though the data channel of the NIC interface is
+bi-directional, we realized that the reversal of the role of the driver does
+not only entail the communication of network payload but also propagation of
+the link state and the MAC address. This prompted us to introduce a new Genode
+session type called "Uplink" that precisely models the NIC-driver-as-client
+scenario.
+
+[image nic_router_services]
+
+In a nutshell, an Uplink session is almost the same as a NIC session with only
+three minor differences. First, the MAC address is given by the client (the
+driver) as an argument at session-creation time. Second, the roles of the TX
+and RX packet streams are interchanged compared to a NIC session. I.e., the
+_client_ transmits via TX and receives through RX while at the server side it's
+vice-versa. And third - as a mere interface optimization - the link state of an
+uplink session is always "up". The session is requested by the client (the
+driver) only in the event of a "link-up" edge. Analogously, whenever the link
+goes "down", the client closes the session again.
+
+With this new session interface in place, the NIC router becomes the only
+long-running component in the scenario. It provides both a NIC and an uplink
+session interface. The NIC session interface is used by network applications.
+The uplink session interface is used by drivers. Inside the router, uplink
+sessions are treated the same as NIC sessions. Therefore, we decided that the
+well known '<policy>' tags in the configuration are now simply applied to both
+session types. This means, that each '<uplink>' tag that connected a driver in a
+router configuration can now be replaced by a '<policy>' tag with a label
+attribute that matches the driver's session request.
+
+[image nic_uplink_multi_app]
+
+We divided the process for this architectural change into the following
+autonomous steps:
+
+# Introduce the uplink session and uplink-session support in the NIC router.
+# Let NIC drivers support both modes, "NIC session server" and "Uplink session
+  client" depending on a new _transitional_ <config>-tag attribute 'mode'.
+  This attribute is optional and has two possible values, 'uplink_client'
+  and 'nic_server', of which it defaults to the latter.
+# Adapt all network scenarios in the basic Genode repositories to use NIC
+  drivers only with '<config mode="uplink_client">'.
+# Remove support for the "NIC session server" mode from all NIC drivers and
+  with it also the transitional 'mode' attribute.
+
+All steps except the last one are completed by now. The transitional 'mode'
+attribute and the "NIC session server" mode will remain available in all NIC
+drivers until the next Genode release in order to give others the opportunity
+to gracefully adapt their NIC drivers and network scenarios to the change.
+
+
+Further information
+-------------------
+
+The overarching topic of pluggable device drivers was covered by our recent
+presentation at [https://fosdem.org/2021/ - FOSDEM 2021]. You can find the
+video recording and the presentation slides at the following link.
+
+:Pluggable device drivers for Genode:
+
+  _presented at FOSDEM 2021_
+
+  [https://fosdem.org/2021/schedule/event/microkernel_pluggable_device_drivers_for_genode/]
+
+
+LTE modem stack
+###############
+
+With the current release, Genode adds LTE broadband modem support for packet data
+connections. This way, it becomes possible to browse the internet using the SIM
+card of your broadband service provider. For a description of the protocols and
+the general terminology when talking about LTE modems, our
+[https://genodians.org/ssumpf/2020-12-04-mbim - LTE modem support for Genode]
+Genodians article is a good starting point.
+
+From the device side, LTE modems register themselves as USB devices at the USB
+host controller. The speciality is that a modem offers two interfaces. First, a USB
+network interface (like NCM or ECM) and second, a
+[https://www.usb.org/document-library/class-definitions-communication-devices-12 - Wireless Mobile Communication Device],
+which is a challenge/response control channel to the modem and used to configure
+the device. For the actual communication through the control channel, there exist two
+binary protocols: Namely, Mobile Broadband Interface Model (MBIM) and Qualcomm
+Mobile Station Interface (QMI). Whereas the former is a USB standard, QMI is a
+proprietary protocol by Qualcomm. Therefore, we picked a modem that supports the
+MBIM standard for our line of work.
+
+
+USB modem support
+=================
+
+In order to enable modem communication, we added the Linux USB modem driver for
+MBIM to our _dde_linux_ device driver environment. This driver implements the
+NCM and WDM interfaces for the modem and provides a network uplink session for
+the NCM network interface and a terminal session for the WDM interface.
+
+[image lte_mbim]
+
+
+MBIM protocol
+=============
+
+MBIM is a binary protocol that is, for example, implemented by
+[https://www.freedesktop.org/wiki/Software/libmbim/ - libmbim]. Therefore, we
+ported _libmbim_ to Genode. Since it requires _glib_, we had to enable features
+and improve our _glib_ support on Genode. The _libmbim_ library offers MBIM command handling only.
+For actually triggering modem-communication, the _mbimcli_ tool is required. We
+ported _mbimcli_ and changed its front end to trigger a modem packet-connection
+sequence via _libmbim_ through the terminal session of the USB modem driver.
+During this sequence, the SIM card is unlocked through the PIN, the packet
+service is attached, and connection information (e.g., IP, gateway, DNS server)
+is retrieved. The connection data is then used by _mbimcli_ to configure the
+uplink of Genode's NIC router, which in turn makes the network connectivity available
+to network applications. The holistic view is shown in image [lte_mbim].
+
+
+Base framework and OS-level infrastructure
+##########################################
+
+NIC router
+==========
+
+The NIC router received two practical features, the consideration of
+multiple DNS server entries on DHCP and an ARP-less mode for domains.
+
+The latter was motivated by the fresh support for LTE modems (see Section
+[LTE modem stack]). An LTE modem normally doesn't respond to ARP. So when
+using it as uplink for the NIC router, the corresponding domain can't request
+IP-to-MAC-address resolutions as usual. This is addressed through the new
+optional attribute 'use_arp' in '<domain>' tags of the NIC router configuration.
+By default, it is set to 'yes', which yields the same behavior as in the past.
+
+However, when set to 'no' for a domain, this domain will prevent sending ARP
+requests in general. This leaves the question how to determine the destination
+MAC address for a packet that shall be sent at this domain when only the
+destination IP address is known. This is solved by the router by simply using
+the source MAC address also as destination MAC address, an approach that we
+could observe also in other IP stacks and that worked just fine in our tests.
+The ARP-less domain mode is demonstrated through the run script
+_repos/os/run/nic_router_disable_arp.run_.
+
+The consideration of multiple DNS-server entries on DHCP comes in two parts.
+First, when acting as DHCP client at a domain, the router will now parse all
+option 6 entries in DHCP ACK replies from the server and memorize them as part
+of the resulting IP config of the domain. These entries will then also be
+reported if '<report config="yes"/>' is set in the router's config. A router
+report with multiple DNS server entries will look like this:
+
+! <state>
+!   <domain name="uplink_1" ipv4="10.0.0.3/24" gw="10.0.0.1">
+!     <dns ip="10.0.0.2"/>
+!     <dns ip="1.1.1.1"/>
+!     <dns ip="8.8.8.8"/>
+!     ...
+!   </domain>
+!   <domain name="uplink_2" ipv4="168.192.0.200/24" gw="168.192.0.1">
+!     <dns ip="168.192.0.10"/>
+!     <dns ip="168.192.0.8"/>
+!     ...
+!   </domain>
+!   ...
+! </state>
+
+On the other hand, when acting as DHCP server at a domain, one has two
+options. Option 1 is to configure the DHCP server to fetch DNS server entries
+automatically from another domain:
+
+! <domain name="downlink" interface="10.0.1.1/24">
+!   <dhcp-server dns_server_from="uplink_1" .../>
+! </domain>
+
+In this case, the router will now reflect not only one but all DNS server
+entries from the source domain ("uplink") through the DHCP replies sent at the
+destination domain ("downlink") without changing the entry order. This approach
+is demonstrated through the new _repos/os/run/nic_router_dhcp_unmanaged.run_
+run script.
+
+Option 2 is to configure the DNS server entries manually at the DHCP
+server:
+
+! <domain name="downlink" interface="10.0.1.1/24">
+!   <dhcp-server ...>
+!     <dns-server ip="10.0.0.2"/>
+!     <dns-server ip="1.1.1.1"/>
+!     <dns-server ip="8.8.8.8"/>
+!   </dhcp-server>
+! </domain>
+
+The order of the '<dns-server>' tags determines the order of
+option 6 entries in the replies of the DHCP server. Besides its use for static
+DNS server configurations, this option can also be used for more sophisticated
+forwarding of DNS server entries through a separate management component. The
+management component could listen to the reported IP config of the source
+domains, apply custom policies like address filters to the result, and
+re-configure the DHCP servers of the destination domains accordingly. This
+approach is demonstrated in the new _repos/os/run/nic_router_dhcp_managed.run_
+run script.
+
+Please note that the former 'dns_server' attribute of the '<dhcp-server>' tag
+is no longer considered by the router as the new '<dns-server>' tag replaces it.
+Thus, you might want to adapt your NIC router scenarios accordingly.
+
+
+VFS support for named pipes
+===========================
+
+The VFS-pipe plugin received new support for named pipes. The main motivation was to
+easily stream data from pure Genode components to libc components via
+file-system sessions that can be attached to stdin, stdout, and stderr. This
+feature further makes it possible to chain the data flow between several components together,
+similarly to how it is done on Unix. Additionally, the thread synchronization
+has been improved so that large data chunks can be transferred without
+blocking.
+
+A named pipe can be created by adding a '<fifo>' sub node to the '<pipe>' node
+of the VFS:
+
+! <vfs>
+!   <pipe>
+!     <fifo name="upstream"/>
+!   </pipe>
+!   ...
+! </vfs>
+
+Each pipe is exposed as a set of pseudo files.
+
+! /upstream
+! /.upstream/in/in
+! /.upstream/out/out
+
+The _/upstream_ pseudo file can be opened either as read-only or write-only
+file. It allows for the access of both ends of the pipe. In contrast, each of
+the pseudo files _/.upstream/in/in_ and _/.upstream/out/out_ represents only
+one end of the pipe, which can be subjected to an individual directory-based
+access-control policy.
+
+Thanks to Sid Hussmann for contributing this valuable feature!
+
+
+Terminal
+========
+
+While
+[https://genode.org/documentation/release-notes/20.08#The_GUI_stack__restacked - revising the GUI stack]
+in Genode 20.08, we largely abolished the use of the framebuffer and input
+session interfaces. The graphical terminal, however, still relied on those
+interfaces instead of the GUI session. In practice, there was always a gui_fb
+component needed as an intermediate between the terminal and the GUI server.
+To complete the GUI-stack transition, we changed the terminal to use the GUI
+session directly and adjusted all current scenarios that use the terminal.
+
+One useful feature of the gui_fb component was the definition of an initial
+window size. This enabled packages such as Sculpt's system shell to present
+terminal windows with a reasonable default size smaller than the entire
+screen.
+To accommodate this special case, the initial terminal size can now be
+explicitly configured in the terminal configuration.
+
+! <config>
+!   <initial width="800" height="600"/>
+!   ...
+! </config>
+
+While we were at it, we also enhanced the terminal with the ability to
+dynamically respond to font changes. So the adjustment of the global font
+settings in Sculpt OS takes immediate effect on all terminal windows.
+
+
+OpenSSL 1.1.1i, curl 7.70.0
+===========================
+
+OpenSSL experienced some quite important security updates during the last
+months. This prompted us to update our port to version 1.1.1i. During
+the porting work, we kept an eye on performance and enabled CPU-specific
+optimizations where feasible. Optimizations are enabled by default on
+x86 and ARMv8. For ARMv7, we enable NEON-based functions only when the
+build SPECS include "neon" to support common SoCs that lack these
+capabilities in the default configuration. Please note, the updated
+port does only provide one combined depot archive "openssl" that
+replaces the former "libcrypto" and "libssl" archives. The libraries
+are still distinct for compatibility with existing applications and
+build systems. As a side effect, we also updated the curl library to
+version 7.70, which is compatible with recent OpenSSL versions.
+
+Thanks to Pirmin Duss for his valuable contribution to this update.
+
+
+Virtualization
+##############
+
+VirtualBox 6.1.14
+=================
+
+Genode supports virtualization with VirtualBox
+[https://genode.org/documentation/release-notes/14.02#VirtualBox_on_top_of_the_NOVA_microhypervisor - since 2014].
+Back then, we enabled VirtualBox version 4 to support use cases with unmodified
+Linux and Windows guests like Sculpt's predecessor
+[https://genode.org/documentation/release-notes/15.11#Genode_as_desktop_OS - "Turmvilla"].
+In 2016, we updated VirtualBox to version 5 to enable recent guest OS
+versions notably Ubuntu 16.04 and Windows 10. VirtualBox 5 is an
+integral part of Sculpt OS since its first release.
+
+As VirtualBox 5 is no longer maintained upstream and also shows its age
+when running recent versions of Windows 10, we accepted the challenge
+to once again enable a new version of this VMM. This time we did not
+go for a NOVA-specific port but exclusively use the kernel-agnostic
+virtualization interfaces introduced in
+[https://genode.org/documentation/release-notes/19.05#Kernel-agnostic_virtual-machine_monitors - Genode 19.05].
+This way, VirtualBox 6 is prepared to run on NOVA, seL4, and Fiasco.OC alike with
+minimal extra efforts.
+
+The first development snapshot we publish with this release is ready to
+run Linux and Windows guests with limited support for multiple cores,
+integrates network and USB-passthrough as well as preliminary support
+for Guest Additions like mouse integration and display. We are
+committed to finalize the feature set and optimize the performance of
+VirtualBox 6 until the upcoming Sculpt release but do not plan to replace
+version 5 completely yet. In fact, the update paves the way to explore
+more experimental grounds like enablement of GPU-based
+acceleration of guest OSes.
+
+As a starting point for exploring VirtualBox 6 on Genode, we recommend the run script
+_ports/run/virtualbox6.run_.
+
+
+VirtualBox 5
+============
+
+With this release, we extended our VirtualBox port and made USB
+pass-through more robust.
+
+So far, we most prominently use VirtualBox on Intel systems that feature
+VT-x. This release enables support for also running 64bit guests on AMD
+systems with SVM.
+
+When it comes to USB pass-through support, we rely on the xHCI device-model
+ported from Qemu. With this release, we updated the 3rd-party sources to
+version 5.2.0 and the type of the exposed device has changed to QEMU xHCI. Due to
+this change, older guest OSes - namely Windows 7 - that relied on the NEC
+xHCI device will no longer work.
+
+Thanks to the update, it becomes possible to use USB devices requiring isochronous
+transfers, in particular audio devices, with Windows 10 guests. For now
+we focused on USB-Audio-Class v1 devices using adaptive
+synchronisation, which enables a variety of popular USB headsets for
+the passthrough use case.
+
+A glimpse into our USB machinery unveils that fine-tuned buffering and USB
+transfer configuration is the key to robust USB passthrough. On one hand, the
+handling of isochronous OUT transfers in our host connection batches multiple
+packets and queues transfers, which helps to smoothen out playback in case other
+Genode components utilize the CPU concurrently. On the other hand, the number of
+IN requests queued is increased but the number of packets per request set to 1.
+We obtained the best results by following this configuration observed in Linux
+and Windows guests alike.
+
+
+VirtIO block devices for virtual machines on ARM
+================================================
+
+With release
+[https://genode.org/documentation/release-notes/20.02#Custom_virtual_machine_monitor_on_ARM - 20.02],
+the first VirtIO device models entered Genode's virtual
+machine monitor for ARM. They enabled a virtual machine to access network and
+terminal services. This time, the VMM got extended with a block device model,
+which again is compliant to the VirtIO 1.1 specification. Moreover, the generic
+model implementation, which is common to all VirtIO devices, got polished fairly.
+
+The new block device model is not configurable yet. By now, the VMM is
+hard-coded to provide exactly one block device. Consequently, one route to a
+Block service needs to be provided to the VMM component.
+
+The execution of the test run-script in _repos/os/run/vmm_arm.run_ shows
+the new VirtIO block device in action.
+
+
+Device drivers
+##############
+
+Power-gating of PCI devices on x86
+==================================
+
+PCI devices have several PCI capabilities that describe the feature set
+the device supports, as defined by the PCI specification. The platform driver - which
+is the gatekeeper of devices on Genode - got extended to power on and power off
+devices whenever the PCI power capability is supported. When powering on, a device reset
+is issued if it is supported by the PCI device. During release of a driver from a
+device, all DMA memory associated to the device is
+flushed from the IO-MMU TLB to avoid any further access.
+
+Additionally, the platform driver has become able to respond to configuration
+changes. Special care must be taken if the configuration of a running device
+driver changes. If the configuration re-evaluation concludes that a driver is no longer
+permitted to use an already assigned PCI device, the Platform session
+will be closed forcefully, making the device inaccessible to the driver.
+
+The extended features of the platform driver supplement our previous work of
+restarting respectively replacing a running graphics driver in Sculpt OS. The driver
+manager, as used by Sculpt, uses Genode's heartbeat monitoring to check for the
+liveliness of the Intel framebuffer driver and restarts it automatically if the
+driver becomes unresponsive. Restarting
+involves closing the Platform session, thereby powering off the Intel device,
+and reopening the Platform session, thereby powering and resetting the
+Intel device into a functional state.
+This self-healing mechanism can be seen in action in the recording of our
+[https://fosdem.org/2021/schedule/event/microkernel_pluggable_device_drivers_for_genode/ - FOSDEM talk]
+about pluggable device drivers.
+
+
+USB drivers
+===========
+
+Additional HID devices
+~~~~~~~~~~~~~~~~~~~~~~
+
+It's a sad truth that some popular USB keyboards and mice do not fully
+comply with the USB HID standard. The Linux kernel comes with dozens
+of special functions to fix up quirks and enable these devices
+for Linux systems also. With the current release, we adopt quirk functions
+for Apple HID devices and mice based on the Holtek chipset (e.g., the
+Sharkoon Drakonia) that are applied automatically if one of these
+devices is plugged.
+
+
+USB robustness
+~~~~~~~~~~~~~~
+
+We improved the robustness of the USB HID driver with regard to device
+reconnection, as well as the robustness of the DWC OTG host driver for
+the Raspberry Pi when used with HID devices.
+
+
+Isochronous transfers
+~~~~~~~~~~~~~~~~~~~~~
+
+While looking more closely into supporting isochronous transfers
+driven by the USB pass-through use-case, we encountered and addressed shortcomings
+in the current implementation in the USB host-controller driver
+when dealing with IN transfers containing multiple isochronous frames.
+However, this is only a first step as we identified significant potential for
+optimization and robustness improvements.
+
+
+Platforms
+#########
+
+Pine-A64-LTS single board computer
+==================================
+
+Our [https://genode.org/about/road-map - road map] envisions
+the use of Genode on the Pinephone by the end of the year. As a first stepping
+stone, the current release adds basic board support for the
+[https://pine64.com/product-category/pine-a64-ltslong-term-supply/ - Pine-A64-LTS]
+single-board computer. We take this line of work as a welcome opportunity to
+thoroughly document the porting process. You can find the work explained in
+great detail in the following article series.
+
+# [https://genodians.org/nfeske/2020-12-10-pine-fun-warmup - Warming up for some Pine fun]
+# [https://genodians.org/nfeske/2020-12-17-pine-fun-serial - Bare-metal serial output]
+# [https://genodians.org/nfeske/2021-01-28-pine-fun-kernel-skeleton - Kernel skeleton]
+# [https://genodians.org/nfeske/2021-02-11-pine-fun-debugging - How did we come here?]
+# [https://genodians.org/nfeske/2021-02-18-pine-fun-user-land - Excursion to the user land]
+
+The latest state of this line of work is available at a dedicated repository:
+
+:Genode board support for Allwinner SoCs:
+
+  [https://github.com/nfeske/genode-allwinner]
+
+
+RISC-V
+======
+
+RISC-V development has been on the hold at Genode Labs for a while. But with the
+current release this has changed. One of the main goals we had for a long time
+is the use of Qemu instead of the Spike emulator for our test infrastructure, since
+every other platform runs on Qemu, Spike causes additional overhead at Genode
+Labs.
+By updating the privileged ISA specification support from 1.9.1 to 1.10,
+we became able to use recent Qemu versions (e.g., 4.2.1).
+Thanks to this change, we could remove the _spike_ board and add a new
+_riscv_qemu_ board to our _base_hw_ kernel implementation.
+
+As another nice side effect, Qemu ships its own OpenSBI machine binary, which
+implements the machine mode and SBI calls. It can be enabled through the "-bios"
+command line option. With a machine mode for ISA 1.10 in place, we were able to
+remove the old [https://github.com/ssumpf/bbl-lite - BBL] machine mode
+implementation from Genode.
+For more information on this topic please refer to the corresponding
+[https://genodians.org/ssumpf/2021-02-24-riscv - Genodians article].
+
+In order to improve development speed, we were able to reduce the link time for
+_core_ and its debugging variant from about 50 to 5 seconds. Additionally, we
+fixed long standing link errors that were caused by mixing up soft float and
+hard float objects as well as misconfigured linker scripts.
+
+
+Removal of Muen separation kernel support
+=========================================
+
+Since
+[https://genode.org/documentation/release-notes/15.08#Genode_on_top_of_the_Muen_Separation_Kernel - version 15.08],
+Genode supported the use of the [https://muen.sk - Muen] separation kernel as
+underlying platform. The driving force behind the original development was the
+joyful collaboration with the Muen developers Adrian-Ken Rueegsegger and Reto
+Buerki and the prospect for products that combine the rigidity of a separation
+kernel with the dynamic workloads enabled by Genode.
+
+However, over the past 5 years, this potential synergy remained untapped.
+In hindsight, the stacking of one microkernel-based system onto another
+microkernel-based system is a tough sell. Hosting dynamic workloads in a Linux
+VM atop Muen is certainly more relatable to Muen users. Vice versa, for Genode
+users, Genode on bare hardware is less complex and more flexible than using
+the framework atop a separation kernel.
+
+Without adoption of the joint platform, neither of both teams can justify the
+ongoing effort needed for the continued maintenance of Genode on Muen. Hence,
+we [https://github.com/genodelabs/genode/issues/3995 - concluded] to remove
+Muen as an officially supported platform.
+
+
+Build system and tools
+######################
+
+Streamlined distinction of boards by build and run tools
+========================================================
+
+In
+[https://genode.org/documentation/release-notes/20.05#Board_support_outside_the_Genode_main_repository - Genode 20.05], 
+we introduced the principle ability to decouple board-support packages from
+the project's main repository. We thereby want to enable developers outside
+the Genode core team to port Genode to diverse hardware platforms.
+With the current release, we further refined the structure of the code base and
+the tooling to largely eliminate remaining points of friction when hosting
+board support in external repositories.
+
+We ultimately removed the use of board-specific SPEC values throughout the
+build system and run scripts. SPEC values are now solely used to refer to
+aspects of an instruction-set architecture, e.g., x86, 64bit, or arm_v8a.
+In run scripts, the new convenience function 'have_board' has become the
+preferred way to distinguish the behavior of run scripts depending on the
+targeted board now. It replaces all former uses of 'have_spec <board>'.
+Moreover, the long deprecated option of the _create_builddir_ tool to create
+board-specific build directories has been removed.
+
+To simplify the hosting of board support in separate source-code repositories,
+board-specific properties have moved from run-tool scripts to the new notion
+of *board property directories*. Such directories named
+_<repo>/board/<board>/_ contain files with board-specific information.
+In particular, the 'image_link_address' file contains the physical
+link address of the system image taking the board's physical memory
+constraints into account, and the 'arch' file contains the CPU
+architecture of the SoC. The run tool picks up this information
+from the board-property files.
+
+Furthermore, the *packaging* of the board-specific base-hw kernel has
+become more formalized by leveraging the board-property directories.
+This makes the packaging vastly simpler. Regardless of where the board-support
+is hosted, the _content.mk_ file for a kernel source archive becomes as simple
+as:
+
+! include $(GENODE_DIR)/repos/base-hw/recipes/src/base-hw_content.inc
+
+The board name is automatically inferred from the path of the src recipe. The
+architecture is determined from _board/<name>/arch_ files. The attempt to
+build a base-hw-<board> binary archive for the wrong architecture is now
+gracefully handled by skipping all targets (using the REQUIRES mechanism).
+
+Besides the improved convenience, the resulting depot archives
+have become much closer tailored to the actual board by omitting files for
+architectures that are not used by the board. E.g., the src/base-hw-pc
+archive does not contain any ARM-related content.
+
+
+Compiler cache
+==============
+
+The [https://ccache.dev - ccache] tool is a fantastic way to accelerate the
+developer workflow when repeatedly building software. Since ccache is -
+strictly speaking - orthogonal to the build system, configuring the Genode
+build system for the use of ccache was left to each developer.
+
+Setting up ccache is not straight-forward though. One must manually create
+hooks (symlinks shadowing the compiler executables), tweak the PATH
+environment variable, and customize the CROSS_DEV_PREFIX in
+_etc/tools.conf_. In short, only seasoned developers jump through those hoops.
+Many others may miss out on the joys of ccache.
+
+With the current release, the build-system front end makes ccache easily
+available by enabling a simple option in the _etc/build.conf_ file:
+
+! CCACHE := yes
+

doc/road_map.txt

@@ -14,121 +14,92 @@ The road map is not fixed. If there is commercial interest of pushing the
 Genode technology to a certain direction, we are willing to revisit our plans.
 
 
-Review of 2019
+Review of 2020
 ##############
 
-For the road map 2019, we picked "bridging worlds" as our guiding theme:
-(1) Lowering the friction when combining existing software with Genode,
-(2) Fostering interoperability with widely used protocols and APIs, and
-(3) Making Genode easier to approach and generally more practical.
+The overarching theme of our road map for 2020 was "Dwarfing the barrier of
+entry", which expressed the ambition to reach a wider audience. On that
+account, we identified four promising directions: First, making Sculpt OS
+palatable for a wider circle. Second, fostering the public perception of the
+high quality of Genode to reinforce the confidence of people who are sceptical
+towards novel operating-system technology. Third, lowering the barrier of
+entry by providing frictionless tooling. And fourth, publicly presenting use
+cases that prove the fitness and flexibility of Genode. These directions
+certainly did a good job of motivating the working topics of last year's four
+releases
+[https://genode.org/documentation/release-notes/20.02 - 20.02],
+[https://genode.org/documentation/release-notes/20.05 - 20.05],
+[https://genode.org/documentation/release-notes/20.08 - 20.08], and
+[https://genode.org/documentation/release-notes/20.11 - 20.11].
 
-With respect to (1), we identified Genode's custom tooling (build
-system, run scripts, ports mechanism, depot tools) as a point of
-friction. They are arguably powerful and flexible but require a lot of
-up-front learning. This is certainly a burden unacceptable for a casual
-developer without a black belt in Make and Expect/Tcl. The new
-[https://genode.org/documentation/release-notes/19.11#New_tooling_for_bridging_existing_build_systems_with_Genode - Goa]
-tool rearranges the existing tools in a way that puts the concerns of casual
-developers into focus, allowing for the use of commodity build systems,
-eliminating Tcl syntax from the equation, running sub-second test cycles, and
-streamlining the packaging of software.
+The UI improvements of Sculpt OS in version 20.02 largely eliminated the need
+to use the command line as presented
+[https://www.youtube.com/watch?v=vmgWgzeKAjU - here].
+The second direction - software quality - motivated the steady improvements of
+our POSIX runtime, ultimately enabling highly sophisticated workloads like the
+Chromium web engine on Genode. Regarding our stated commitment to 64-bit ARM
+hardware, in particular supporting the NXP i.MX8 SoC, we covered 64-bit
+multi-core virtualization, HDMI, touch input, OLED, networking, LTE, USB,
+clock and power management, VirtIO, up to running Sculpt OS on this platform.
 
-On account of (2), we
-[https://genode.org/documentation/release-notes/19.05#Broadened_CPU_architecture_support_and_updated_tool_chain - switched to C++17]
-by default, fostered the use of
-[https://genodians.org/ssumpf/2019-02-27-java-19-02 - Java],
-updated Qt5, and put
-[https://genode.org/documentation/release-notes/19.11#C_runtime_with_improved_POSIX_compatibility - POSIX]
-compatibility into the spotlight. We were eventually able to dissolve the need
-for our custom Unix runtime (Noux) because all features of Noux are covered by
-our regular libc now.
-
-Our biggest step towards (3) is the [https://genodians.org] website we
-started in winter 2019, which gives individual members of our community
-an easy way to present thoughts, projects, and experiences.
-Complementing Genode's formal documentation, it also conserves practical
-tips and tricks that were previously not covered in written form.
-
-When speaking of "bridging worlds", we should not forget to mention the
-tremendous effort to bring Sculpt-OS-like workloads to the 64-bit ARM world.
-Thanks to the added support for
-[https://genode.org/documentation/release-notes/19.08#64-bit_ARM_and_NXP_i.MX8 - multi-core AARCH64],
-hardware-based
-[https://genode.org/documentation/release-notes/19.11#Virtualization_of_64-bit_ARM_platforms - virtualization],
-and network/USB/graphics drivers for the i.MX8 SoC, the flexibility of Sculpt
-OS will eventually become available on PC hardware and ARM-based devices
-alike.
-
-Over the course of 2019, we admittedly skipped a few topics originally
-mentioned on our road map. In particular, the user-visible side of
-Sculpt OS received less attention than originally envisioned. We also
-deferred several ideas we had in mind about reworking our GUI stack.
-Instead, we expanded our work in the areas of storage (block-level APIs,
-test infrastructure,
-[https://genode.org/documentation/release-notes/19.11#Preliminary_block-device_encrypter - block encryption])
-and
-[https://genode.org/documentation/release-notes/19.08#Flexible_keyboard_layouts - input processing].
-This shift of focus is mostly attributed to the priorities of Genode Labs'
-customers who fund our work.
+Granted, Genode's audience hasn't increased by a large margin as a direct
+result of these efforts. But as illustrated by the fruitful road-map
+discussion for 2021 on the
+[https://genode.org/community/mailing-lists - mailing list],
+our community is more engaged and enthusiastic than ever before.
 
 
-2020 - Dwarfing the barrier of entry
-####################################
+2021 - Optimization and Platform diversity
+##########################################
 
-Genode as a technology is there. For more than one decade, we walked unfathomed
-territory, fought with countless deep rabbit holes, took risky decisions,
-tracked back, explored design spaces, developed taste and distaste, pruned
-technical debt, and eventually found formulas of success. Today, there are no
-(fundamental) unsolved questions. All the puzzle pieces are in place. There
-could be no better proof than our daily use of Sculpt OS. The time is right
-to make Genode palatable for a wider circle. We identified four actionable
-topics to achieve that.
+For the initial conquering of 64-bit ARM territory, restraining our focus to
+one particular SoC - namely NXP i.MX8 - was a healthy approach. Now it is the
+right time to optimize and to branch out the development to further
+platforms. The following key aspects of our road map for 2021 reflect that.
 
-:User friendliness of Sculpt OS:
+:Pinephone:
+  By the end of the year, we want be able to use Genode on the
+  [https://pine64.com/product-category/pinephone/ - Pinephone]
+  as a feature phone, covering basic web-browsing needs, placing calls, and
+  SMS.
 
-  Until now, Sculpt OS is not exactly friendly towards users who are
-  unfamiliar with the Unix command-line tools. Since Sculpt is not Unix
-  based, this is a bit paradoxical. 2020 will give Sculpt OS a friendlier
-  and discoverable user experience. In this context, we will inevitably
-  put our attention to Genode's GUI stack.
+:Linux-device-driver environment re-imagined:
+  We are convinced that we have to dramatically reduce the engineering
+  effort needed to port device drivers from the Linux kernel to Genode. With
+  many years of driver-porting experience under our belts, we plan to condense
+  the lessons learned in the form of new tooling and documentation. This, in
+  turn, will hopefully pave the ground for more and more developers
+  contributing to Genode's device-driver coverage in the future.
 
-:Perception of high quality:
+:Developer experience:
+  Speaking of new developers, we see Genode's existing tool set as a barrier
+  because it requires a rather steep learning curve. Hence, this year, we will
+  have a fresh take on tooling and workflows. The starting point will be the
+  experimental [https://github.com/nfeske/goa - Goa] tool, which in principle
+  allows developers to use familiar build systems for Genode development. We
+  plan to extend Goa to cover more build systems, and shape the tool towards
+  system-integration tasks and quick compile-test cycles targeting embedded
+  devices.
 
-  Compared to commodity operating systems who stood the test of time,
-  Genode is a young and largely unproven technology. It understandably calls
-  for skepticism. All the more we must leave no doubts about our high
-  quality standards. There must be no room for uncertainty. Hence, during
-  2020, we will intensify the consolidation and optimization of the framework
-  and its API, and talk about it.
+:Optimization:
+  Motivated by usage scenarios like the Pinephone, we are eager to tap into
+  plenty of opportunities for optimization. Based on data gathered by improved
+  system tracing, we consider interface refinements to improve the batching of
+  I/O (file-system access, networking), micro-optimizations of hot code paths
+  (like TLS lookup, parsers, and allocators), as well as structural changes
+  (like the consolidation of low-level services).
 
-:Enjoyable tooling:
-
-  Genode's success at large will depend on developers. As of today, software
-  development for Genode requires a huge up-front learning curve. This is
-  fine for people who are already convinced of Genode. But it unacceptable
-  for casual developers who want to get their toes wet. We should aim for
-  tooling that allows new developers to keep up their flow and beloved
-  tools. The recently introduced [https://genodians.org/nfeske/2019-11-25-goa - Goa]
-  tooling is our first take in this respect. It is certainly too early to call
-  Goa a success. In order to find out if we are on the right track, we want to
-  expose Goa to as many problems as possible, primarily by the means of
-  porting software. Also, things like IDE usage or adapters for a variety of
-  build systems will certainly move into focus in 2020.
-
-:Convincing use cases:
-
-  Use cases can give exemplary proof of the fitness of Genode. We already
-  took a few baby steps to extend the range of documented use cases beyond
-  Sculpt OS last year. The boot2java scenenario comes in mind. 2020 will
-  hopefully see several more illustrations of Genode's versatility.
+:GPU support:
+  Distantly related to optimization, GPU support is an increasingly requested
+  feature. We already
+  [https://genode.org/documentation/release-notes/17.08#Hardware-accelerated_graphics_for_Intel_Gen-8_GPUs - wetted our toes]
+  in the past. But GPU support has not yet become routinely supported in
+  system scenarios like Sculpt OS. In 2021, we want to change that, making GPU
+  support a feature that can be relied on. We will primarily address Intel
+  graphics first but also explore GPUs on ARM-based devices.
 
 
-Apart from this overall theme, we plan to continue our commitment to the
-NXP i.MX SoC family, revisit Genode's low-latency audio support, and
-extend the cultivation of Ada/SPARK within (and on top of) Genode.
-
-
-Milestones for 2020
+Milestones for 2021
 ###################
 
 In the following, we present a rough schedule of the planned work. As usual,
@@ -136,64 +107,65 @@ it is not set in stone. If you are interested in a particular line of work,
 please get in touch.
 
 
-February - Release 20.02
+February - Release 21.02
 ========================
 
-* Consolidation: removal of the Noux runtime
-* Library version of the init component
-* Updated audio drivers
-* Sculpt
-  * 64-bit ARM (i.MX8)
-  * Revised administrative user interface
-  * System image without Unix tools
+* Pluggable device drivers (NIC, WLAN, framebuffer, input)
+* VirtualBox 6
+* Sculpt: basic UI for the consistent block encrypter (CBE)
+* 64-bit ARM
+  * VirtIO block-device support for virtual machines
+  * Base platform support for the Pine A64 board (kernel base framework)
 
 
-May - Release 20.05
+May - Release 21.05
 ===================
 
-* Updated "Genode Foundations" book
-* Consolidation
-  * Block-level components (update to Genode's modern block APIs)
-  * ARM device drivers (introducing the notion of a platform driver)
-  * Improved STL support (e.g., threading and mutexes)
-  * Continuous POSIX-compliance testing
-  * Systematic network-stack stress and performance tests
-* Desktop: panel and virtual desktops
-* Use case: Genode-based network router
-* Goa: broadened support for 3rd-party build systems
-* Native tool chain, including Git
-* Sculpt
-  * Interactive device management
-  * Keyboard-controlled administration
-* Support for BSPs maintained outside of Genode's mainline repository
+* Annual documentation update, including the "Genode Foundations" book
+* GPU support
+  * MESA update
+  * Experiments on ARM (e.g., Vivante on i.MX8, or Mali-400 on A64)
+* Sculpt OS on Pine A64 (USB, input, framebuffer, SD-card, networking)
+* 64-bit ARM
+  * Platform-driver consolidation between ARM and x86
+  * PCI-express support for MNT Reform (i.MX8)
+* Tool-chain update (e.g., switching to hard-float on ARM)
+* Modernized client-side NIC and uplink APIs
+* Goa
+  * Broadened architecture support and testing workflow
+  * API projects
+  * Inter-project dependencies
 
 
-August - Release 20.08
+August - Release 21.08
 ======================
 
-* Revisited GUI-related framework interfaces
-* Extended tooling for performance monitoring
-* Goa: Qt development workflow
-* Desktop
-  * Native mail client
-  * Native web browser
-* Sculpt
-  * Configurable CPU resources
-  * On-screen documentation
-  * Block encryption via our
-    [https://genode.org/documentation/release-notes/19.11#Preliminary_block-device_encrypter - consistent block encrypter]
-    implemented in Ada/SPARK
-* USB audio
-* Initial version of a kernel implemented in Ada/SPARK
+* Linux DDE re-imagined
+  * Improved tooling
+  * Exploring Goa-based development workflow
+* GPU support
+  * GPU multiplexer for Intel Gen9 graphics
+  * Harmonization of GPU driver with Intel framebuffer driver
+* Initial version of a custom kernel (Spunky) implemented in Ada/SPARK
+* System-level tracing infrastructure for guiding and validating optimizations
+* Pinephone
+  * Touchscreen and display
+  * Mobile web browser
+* Goa
+  * CMake-based Qt5 applications
+  * QML-based applications
 
 
-November - Release 20.11
+November - Release 21.11
 ========================
 
-* Consolidation of capability-space management across kernels
-* CPU-load balancing
-* Hardware-accelerated graphics on i.MX8 (experimental)
-* Reworked audio stack (interfaces, mixing)
-* Sculpt: component lifetime management, shutdown protocol
-* VFS plugins for lwext4 and FUSE-based file systems
+* Pinephone
+  * Mobile data connectivity (LTE)
+  * Phone calls (audio)
+  * SMS
+* seL4
+  * Update to current kernel version, MCS scheduling
+  * Combining CAmkES with Genode
+* SMMU (I/O-MMU for ARM) support for our custom (base-hw) kernel
+* Multi-monitor support
 

repos/README

@@ -31,33 +31,25 @@ but build upon of each other:
 
   :'nova':
     NOVA hypervisor developed at University of Technology Dresden
-    See [https://genode.org/documentation/platforms/nova]
 
   :'foc':
     Fiasco.OC is a modernized version of the Fiasco microkernel with a
     completely revised kernel interface fostering capability-based
     security. It is not compatible with L4/Fiasco.
-    See [https://genode.org/documentation/platforms/foc]
 
   :'hw':
     The hw platform allows the execution of Genode on bare ARM and x86 hardware
     without the need for a separate kernel. The kernel functionality is
-    included in core except in the special case of the Muen separation
-    kernel.
-    See [https://genode.org/documentation/platforms/hw] and
-    [https://genode.org/documentation/platforms/muen]
+    included in core.
 
   :'okl4':
     OKL4 kernel (x86_32 and ARM) developed at Open-Kernel-Labs.
-    See [https://genode.org/documentation/platforms/okl4]
 
   :'pistachio':
     L4ka::Pistachio kernel developed at University of Karlsruhe.
-    See [https://genode.org/documentation/platforms/pistachio]
 
   :'fiasco':
     L4/Fiasco kernel developed at University of Technology Dresden.
-    See [https://genode.org/documentation/platforms/fiasco]
 
   :'sel4':
     seL4 microkernel developed at NICTA/General Dynamics

repos/base-fiasco/README

@@ -1,4 +1 @@
 This repository contains the L4/Fiasco-specific implementation of Genode.
-
-For instructions to build and start the Fiasco version of Genode, please
-consult the documentation located at 'base-fiasco/doc/fiasco.txt'.

repos/base-fiasco/etc/specs.conf

@@ -1 +1 @@
-SPECS += fiasco x86_32
+SPECS += fiasco

repos/base-fiasco/recipes/src/base-fiasco/hash

@@ -1 +1 @@
-2020-09-16 f9a3892feb099ad542875f5e4a51021dfbbdf982
+2021-03-11 d5d038d82badefdb0ec442be4dc7b23064ad2831

repos/base-fiasco/src/core/core_log_out.cc

@@ -14,7 +14,10 @@
 /* core includes */
 #include <core_log.h>
 
-namespace Fiasco {
-#include <l4/sys/kdebug.h>
-}
-void Genode::Core_log::out(char const c) { Fiasco::outchar(c); }
+/* L4/Fiasco includes */
+#include <fiasco/syscall.h>
+
+using namespace Genode;
+
+
+void Core_log::out(char const c) { Fiasco::outchar(c); }

repos/base-fiasco/src/core/fiasco/target.mk

@@ -1,4 +1,4 @@
 LIBS     := core-fiasco
-CORE_OBJ := core-fiasco.o
+CORE_LIB := core-fiasco.a
 
 include $(BASE_DIR)/src/core/target.inc

repos/base-fiasco/src/core/include/ipc_pager.h

@@ -27,154 +27,153 @@
 /* core includes */
 #include <util.h>
 
-/* Fiasco includes */
-namespace Fiasco {
-#include <l4/sys/types.h>
-}
+/* L4/Fiasco includes */
+#include <fiasco/syscall.h>
 
 namespace Genode {
 
-	class Mapping
-	{
-		private:
-
-			addr_t             _dst_addr;
-			Fiasco::l4_fpage_t _fpage;
-
-		public:
-
-			/**
-			 * Constructor
-			 */
-			Mapping(addr_t dst_addr, addr_t src_addr,
-			        Cache_attribute cacheability, bool,
-			        unsigned l2size, bool rw, bool)
-			:
-				_dst_addr(dst_addr),
-				_fpage(Fiasco::l4_fpage(src_addr, l2size, rw, false))
-			{
-				if (cacheability == WRITE_COMBINED)
-					_fpage.fp.cache = Fiasco::L4_FPAGE_BUFFERABLE;
-			}
-
-			/**
-			 * Construct invalid flexpage
-			 */
-			Mapping() : _dst_addr(0), _fpage(Fiasco::l4_fpage(0, 0, 0, 0)) { }
-
-			Fiasco::l4_umword_t dst_addr() const { return _dst_addr; }
-			Fiasco::l4_fpage_t  fpage()    const { return _fpage; }
-
-			/**
-			 * Prepare map operation
-			 *
-			 * On Fiasco, we need to map a page locally to be able to map it to
-			 * another address space.
-			 */
-			void prepare_map_operation()
-			{
-				addr_t core_local_addr = _fpage.fp.page << 12;
-				size_t mapping_size    = 1 << _fpage.fp.size;
-
-				for (addr_t i = 0; i < mapping_size; i += L4_PAGESIZE) {
-					if (_fpage.fp.write)
-						touch_read_write((unsigned char volatile *)(core_local_addr + i));
-					else
-						touch_read((unsigned char const volatile *)(core_local_addr + i));
-				}
-			}
-	};
-
-
-	/**
-	 * Special paging server class
-	 */
-	class Ipc_pager
-	{
-		private:
-
-			Fiasco::l4_threadid_t _last          { };    /* origin of last fault message   */
-			addr_t                _pf_addr       { 0 };  /* page-fault address             */
-			addr_t                _pf_ip         { 0 };  /* instruction pointer of faulter */
-			Mapping               _reply_mapping { };    /* page-fault answer              */
-
-		public:
-
-			/**
-			 * Wait for a new page fault received as short message IPC
-			 */
-			void wait_for_fault();
-
-			/**
-			 * Reply current page-fault and wait for a new one
-			 *
-			 * Send short flex page and wait for next short-message (register)
-			 * IPC -- pagefault
-			 */
-			void reply_and_wait_for_fault();
-
-			/**
-			 * Request instruction pointer of current page fault
-			 */
-			addr_t fault_ip() { return _pf_ip; }
-
-			/**
-			 * Request fault address of current page fault
-			 */
-			addr_t fault_addr() { return _pf_addr & ~3; }
-
-			/**
-			 * Set parameters for next reply
-			 */
-			void set_reply_mapping(Mapping m) { _reply_mapping = m; }
-
-			/**
-			 * Set destination for next reply
-			 */
-			void set_reply_dst(Native_capability pager_object) {
-				_last.raw = pager_object.local_name(); }
-
-			/**
-			 * Answer call without sending a flex-page mapping
-			 *
-			 * This function is used to acknowledge local calls from one of
-			 * core's region-manager sessions.
-			 */
-			void acknowledge_wakeup();
-
-			/**
-			 * Returns true if the last request was send from a core thread
-			 */
-			bool request_from_core()
-			{
-				enum { CORE_TASK_ID = 4 };
-				return _last.id.task == CORE_TASK_ID;
-			}
-
-			/**
-			 * Return badge for faulting thread
-			 *
-			 * As Fiasco has no server-defined badges for page-fault messages, we
-			 * interpret the sender ID as badge.
-			 */
-			unsigned long badge() const {
-				return convert_native_thread_id_to_badge(_last); }
-
-			bool write_fault() const { return (_pf_addr & 2); }
-
-			bool exec_fault()  const { return false; }
-
-			/**
-			 * Return true if last fault was an exception
-			 */
-			bool exception() const
-			{
-				/*
-				 * Reflection of exceptions is not supported on this platform.
-				 */
-				return false;
-			}
-	};
+	class Mapping;
+	class Ipc_pager;
 }
 
+
+class Genode::Mapping
+{
+	private:
+
+		addr_t             _dst_addr;
+		Fiasco::l4_fpage_t _fpage;
+
+	public:
+
+		/**
+		 * Constructor
+		 */
+		Mapping(addr_t dst_addr, addr_t src_addr,
+		        Cache_attribute cacheability, bool,
+		        unsigned l2size, bool rw, bool)
+		:
+			_dst_addr(dst_addr),
+			_fpage(Fiasco::l4_fpage(src_addr, l2size, rw, false))
+		{
+			if (cacheability == WRITE_COMBINED)
+				_fpage.fp.cache = Fiasco::L4_FPAGE_BUFFERABLE;
+		}
+
+		/**
+		 * Construct invalid flexpage
+		 */
+		Mapping() : _dst_addr(0), _fpage(Fiasco::l4_fpage(0, 0, 0, 0)) { }
+
+		Fiasco::l4_umword_t dst_addr() const { return _dst_addr; }
+		Fiasco::l4_fpage_t  fpage()    const { return _fpage; }
+
+		/**
+		 * Prepare map operation
+		 *
+		 * On Fiasco, we need to map a page locally to be able to map it to
+		 * another address space.
+		 */
+		void prepare_map_operation()
+		{
+			addr_t core_local_addr = _fpage.fp.page << 12;
+			size_t mapping_size    = 1 << _fpage.fp.size;
+
+			for (addr_t i = 0; i < mapping_size; i += L4_PAGESIZE) {
+				if (_fpage.fp.write)
+					touch_read_write((unsigned char volatile *)(core_local_addr + i));
+				else
+					touch_read((unsigned char const volatile *)(core_local_addr + i));
+			}
+		}
+};
+
+
+class Genode::Ipc_pager
+{
+	private:
+
+		Fiasco::l4_threadid_t _last          { };    /* origin of last fault message   */
+		addr_t                _pf_addr       { 0 };  /* page-fault address             */
+		addr_t                _pf_ip         { 0 };  /* instruction pointer of faulter */
+		Mapping               _reply_mapping { };    /* page-fault answer              */
+
+	public:
+
+		/**
+		 * Wait for a new page fault received as short message IPC
+		 */
+		void wait_for_fault();
+
+		/**
+		 * Reply current page-fault and wait for a new one
+		 *
+		 * Send short flex page and wait for next short-message (register)
+		 * IPC -- pagefault
+		 */
+		void reply_and_wait_for_fault();
+
+		/**
+		 * Request instruction pointer of current page fault
+		 */
+		addr_t fault_ip() { return _pf_ip; }
+
+		/**
+		 * Request fault address of current page fault
+		 */
+		addr_t fault_addr() { return _pf_addr & ~3; }
+
+		/**
+		 * Set parameters for next reply
+		 */
+		void set_reply_mapping(Mapping m) { _reply_mapping = m; }
+
+		/**
+		 * Set destination for next reply
+		 */
+		void set_reply_dst(Native_capability pager_object) {
+			_last.raw = pager_object.local_name(); }
+
+		/**
+		 * Answer call without sending a flex-page mapping
+		 *
+		 * This function is used to acknowledge local calls from one of
+		 * core's region-manager sessions.
+		 */
+		void acknowledge_wakeup();
+
+		/**
+		 * Returns true if the last request was send from a core thread
+		 */
+		bool request_from_core()
+		{
+			enum { CORE_TASK_ID = 4 };
+			return _last.id.task == CORE_TASK_ID;
+		}
+
+		/**
+		 * Return badge for faulting thread
+		 *
+		 * As Fiasco has no server-defined badges for page-fault messages, we
+		 * interpret the sender ID as badge.
+		 */
+		unsigned long badge() const {
+			return convert_native_thread_id_to_badge(_last); }
+
+		bool write_fault() const { return (_pf_addr & 2); }
+
+		bool exec_fault()  const { return false; }
+
+		/**
+		 * Return true if last fault was an exception
+		 */
+		bool exception() const
+		{
+			/*
+			 * Reflection of exceptions is not supported on this platform.
+			 */
+			return false;
+		}
+};
+
 #endif /* _CORE__INCLUDE__IPC_PAGER_H_ */

repos/base-fiasco/src/core/include/map_local.h

@@ -18,12 +18,8 @@
 #include <platform.h>
 #include <util.h>
 
-/* Fiasco includes */
-namespace Fiasco {
-#include <l4/sys/ipc.h>
-#include <l4/sys/syscalls.h>
-#include <l4/sys/kdebug.h>
-}
+/* L4/Fiasco includes */
+#include <fiasco/syscall.h>
 
 namespace Genode {
 

repos/base-fiasco/src/core/include/platform.h

@@ -15,9 +15,13 @@
 #ifndef _CORE__INCLUDE__PLATFORM_H_
 #define _CORE__INCLUDE__PLATFORM_H_
 
+/* Genode includes */
 #include <base/allocator_avl.h>
+
+/* base-internal includes */
 #include <base/internal/capability_space.h>
 
+/* core includes */
 #include <synced_range_allocator.h>
 #include <platform_generic.h>
 #include <platform_thread.h>
@@ -25,150 +29,149 @@
 #include <boot_modules.h>
 #include <assertion.h>
 
+namespace Genode { class Platform; }
 
-namespace Genode {
 
-	class Platform : public Platform_generic
-	{
-		private:
+class Genode::Platform : public Platform_generic
+{
+	private:
 
-			/*
-			 * Noncopyable
-			 */
-			Platform(Platform const &);
-			Platform &operator = (Platform const &);
+		/*
+		 * Noncopyable
+		 */
+		Platform(Platform const &);
+		Platform &operator = (Platform const &);
 
-			/*
-			 * Shortcut for the type of allocator instances for physical resources
-			 */
-			typedef Synced_range_allocator<Allocator_avl> Phys_allocator;
+		/*
+		 * Shortcut for the type of allocator instances for physical resources
+		 */
+		typedef Synced_range_allocator<Allocator_avl> Phys_allocator;
 
-			char           _core_label[1];      /* to satisfy _core_pd */
-			Platform_pd   *_core_pd = nullptr;  /* core protection domain object */
-			Phys_allocator _ram_alloc;          /* RAM allocator */
-			Phys_allocator _io_mem_alloc;       /* MMIO allocator */
-			Phys_allocator _io_port_alloc;      /* I/O port allocator */
-			Phys_allocator _irq_alloc;          /* IRQ allocator */
-			Phys_allocator _region_alloc;       /* virtual memory allocator for core */
-			Rom_fs         _rom_fs { };             /* ROM file system */
-			Rom_module     _kip_rom;            /* ROM module for Fiasco KIP */
+		char           _core_label[1];      /* to satisfy _core_pd */
+		Platform_pd   *_core_pd = nullptr;  /* core protection domain object */
+		Phys_allocator _ram_alloc;          /* RAM allocator */
+		Phys_allocator _io_mem_alloc;       /* MMIO allocator */
+		Phys_allocator _io_port_alloc;      /* I/O port allocator */
+		Phys_allocator _irq_alloc;          /* IRQ allocator */
+		Phys_allocator _region_alloc;       /* virtual memory allocator for core */
+		Rom_fs         _rom_fs { };             /* ROM file system */
+		Rom_module     _kip_rom;            /* ROM module for Fiasco KIP */
 
-			addr_t         _vm_start = 0;       /* begin of virtual memory */
-			size_t         _vm_size  = 0;       /* size of virtual memory */
+		addr_t         _vm_start = 0;       /* begin of virtual memory */
+		size_t         _vm_size  = 0;       /* size of virtual memory */
 
-			/*
-			 * We do not export any boot module loaded before FIRST_ROM.
-			 */
-			enum { FIRST_ROM = 3 };
+		/*
+		 * We do not export any boot module loaded before FIRST_ROM.
+		 */
+		enum { FIRST_ROM = 3 };
 
-			/**
-			 * Setup base resources
-			 *
-			 * - Map and provide KIP as ROM module
-			 * - Initializes region allocator
-			 */
-			void _setup_basics();
+		/**
+		 * Setup base resources
+		 *
+		 * - Map and provide KIP as ROM module
+		 * - Initializes region allocator
+		 */
+		void _setup_basics();
 
-			/**
-			 * Setup RAM, IO_MEM, and region allocators
-			 */
-			void _setup_mem_alloc();
+		/**
+		 * Setup RAM, IO_MEM, and region allocators
+		 */
+		void _setup_mem_alloc();
 
-			/**
-			 * Setup I/O port space allocator
-			 */
-			void _setup_io_port_alloc();
+		/**
+		 * Setup I/O port space allocator
+		 */
+		void _setup_io_port_alloc();
 
-			/**
-			 * Setup IRQ allocator
-			 */
-			void _setup_irq_alloc();
+		/**
+		 * Setup IRQ allocator
+		 */
+		void _setup_irq_alloc();
 
-			/**
-			 * Parse multi-boot information and update ROM database
-			 */
-			void _init_rom_modules();
+		/**
+		 * Parse multi-boot information and update ROM database
+		 */
+		void _init_rom_modules();
 
-			/**
-			 * Setup pager for core-internal threads
-			 */
-			void _setup_core_pager();
+		/**
+		 * Setup pager for core-internal threads
+		 */
+		void _setup_core_pager();
 
-			addr_t _rom_module_phys(addr_t virt) { return virt; }
+		addr_t _rom_module_phys(addr_t virt) { return virt; }
 
-		public:
-
-			/**
-			 * Pager object representing the pager of core namely sigma0
-			 */
-			struct Sigma0 : public Pager_object
-			{
-				/**
-				 * Constructor
-				 */
-				Sigma0();
-
-				int pager(Ipc_pager &) override { /* never called */ return -1; }
-			};
-
-			/**
-			 * Return singleton instance of Sigma0 pager object
-			 */
-			static Sigma0 &sigma0();
-
-			/**
-			 * Core pager thread that handles core-internal page-faults
-			 */
-			struct Core_pager : public Platform_thread, public Pager_object
-			{
-				/**
-				 * Constructor
-				 */
-				Core_pager(Platform_pd &core_pd);
-
-				int pager(Ipc_pager &) override { /* never called */ return -1; }
-			};
-
-			/**
-			 * Return singleton instance of core pager object
-			 */
-			Core_pager &core_pager();
+	public:
 
+		/**
+		 * Pager object representing the pager of core namely sigma0
+		 */
+		struct Sigma0 : public Pager_object
+		{
 			/**
 			 * Constructor
 			 */
-			Platform();
+			Sigma0();
 
+			int pager(Ipc_pager &) override { /* never called */ return -1; }
+		};
+
+		/**
+		 * Return singleton instance of Sigma0 pager object
+		 */
+		static Sigma0 &sigma0();
+
+		/**
+		 * Core pager thread that handles core-internal page-faults
+		 */
+		struct Core_pager : public Platform_thread, public Pager_object
+		{
 			/**
-			 * Accessor for core pd object
+			 * Constructor
 			 */
-			Platform_pd &core_pd()
-			{
-				if (_core_pd)
-					return *_core_pd;
+			Core_pager(Platform_pd &core_pd);
 
-				ASSERT_NEVER_CALLED;
-			}
+			int pager(Ipc_pager &) override { /* never called */ return -1; }
+		};
+
+		/**
+		 * Return singleton instance of core pager object
+		 */
+		Core_pager &core_pager();
+
+		/**
+		 * Constructor
+		 */
+		Platform();
+
+		/**
+		 * Accessor for core pd object
+		 */
+		Platform_pd &core_pd()
+		{
+			if (_core_pd)
+				return *_core_pd;
+
+			ASSERT_NEVER_CALLED;
+		}
 
 
-			/********************************
-			 ** Generic platform interface **
-			 ********************************/
+		/********************************
+		 ** Generic platform interface **
+		 ********************************/
 
-			Range_allocator &core_mem_alloc() override { return _ram_alloc; }
-			Range_allocator &ram_alloc()      override { return _ram_alloc; }
-			Range_allocator &io_mem_alloc()   override { return _io_mem_alloc; }
-			Range_allocator &io_port_alloc()  override { return _io_port_alloc; }
-			Range_allocator &irq_alloc()      override { return _irq_alloc; }
-			Range_allocator &region_alloc()   override { return _region_alloc; }
-			addr_t           vm_start() const override { return _vm_start; }
-			size_t           vm_size()  const override { return _vm_size; }
-			Rom_fs          &rom_fs()         override { return _rom_fs; }
+		Range_allocator &core_mem_alloc() override { return _ram_alloc; }
+		Range_allocator &ram_alloc()      override { return _ram_alloc; }
+		Range_allocator &io_mem_alloc()   override { return _io_mem_alloc; }
+		Range_allocator &io_port_alloc()  override { return _io_port_alloc; }
+		Range_allocator &irq_alloc()      override { return _irq_alloc; }
+		Range_allocator &region_alloc()   override { return _region_alloc; }
+		addr_t           vm_start() const override { return _vm_start; }
+		size_t           vm_size()  const override { return _vm_size; }
+		Rom_fs          &rom_fs()         override { return _rom_fs; }
 
-			size_t max_caps() const override { return Capability_space::max_caps(); }
+		size_t max_caps() const override { return Capability_space::max_caps(); }
 
-			void wait_for_exit() override;
-	};
-}
+		void wait_for_exit() override;
+};
 
 #endif /* _CORE__INCLUDE__PLATFORM_H_ */

repos/base-fiasco/src/core/include/platform_pd.h

@@ -17,188 +17,193 @@
 #ifndef _CORE__INCLUDE__PLATFORM_PD_H_
 #define _CORE__INCLUDE__PLATFORM_PD_H_
 
+/* Genode includes */
 #include <base/allocator.h>
+
+/* core includes */
 #include <platform_thread.h>
 #include <address_space.h>
 
-namespace Fiasco {
-#include <l4/sys/types.h>
-}
+/* L4/Fiasco includes */
+#include <fiasco/syscall.h>
 
 namespace Genode {
 
 	class Platform_thread;
-	class Platform_pd : public Address_space
-	{
-		private:
-
-			/*
-			 * Noncopyable
-			 */
-			Platform_pd(Platform_pd const &);
-			Platform_pd &operator = (Platform_pd const &);
-
-			enum {
-				VERSION_BITS   = 10,
-				PD_FIRST       = 0x10,
-				PD_MAX         = (1 << 11) - 1, /* leave 0x7ff free for L4_INVALID_ID */
-				PD_VERSION_MAX = (1 << 10) - 1,
-				PD_INVALID     = -1,
-				THREAD_MAX     = (1 << 7),
-			};
-
-			unsigned _pd_id   = 0;
-			unsigned _version = 0;
-
-			Fiasco::l4_taskid_t _l4_task_id { };  /* L4 task ID */
-
-
-			/**********************************************
-			 ** Threads of this protection domain object **
-			 **********************************************/
-
-			Platform_thread *_threads[THREAD_MAX];
-
-			/**
-			 * Initialize thread allocator
-			 */
-			void _init_threads();
-
-			/**
-			 * Thread iteration for one task
-			 */
-			Platform_thread *_next_thread();
-
-			/**
-			 * Thread allocation
-			 *
-			 * Again a special case for Core thread0.
-			 */
-			int _alloc_thread(int thread_id, Platform_thread &thread);
-
-			/**
-			 * Thread deallocation
-			 *
-			 * No special case for Core thread0 here - we just never call it.
-			 */
-			void _free_thread(int thread_id);
-
-
-			/******************
-			 ** PD allocator **
-			 ******************/
-
-			struct Pd_alloc
-			{
-				unsigned reserved : 1;
-				unsigned free     : 1;
-				unsigned version  : VERSION_BITS;
-
-				Pd_alloc(bool r, bool f, unsigned v)
-				: reserved(r), free(f), version(v) { }
-
-				Pd_alloc() : reserved(0), free(0), version(0) { }
-			};
-
-			static Pd_alloc *_pds()
-			{
-				static Pd_alloc static_pds[PD_MAX];
-				return static_pds;
-			}
-
-			/**
-			 * Protection-domain creation
-			 *
-			 * The syscall parameter propagates if any L4 kernel function
-			 * should be used. We need the special case for the Core startup.
-			 */
-			void _create_pd(bool syscall);
-
-			/**
-			 * Protection domain destruction
-			 *
-			 * No special case for Core here - we just never call it.
-			 */
-			void _destroy_pd();
-
-			/**
-			 * Protection domain allocation
-			 *
-			 * Find free L4 task and use it. We need the special case for Core
-			 * startup.
-			 */
-			int _alloc_pd(signed pd_id);
-
-			/**
-			 * Protection domain deallocation
-			 *
-			 * No special case for Core here - we just never call it.
-			 */
-			void _free_pd();
-
-
-			/***************
-			 ** Debugging **
-			 ***************/
-
-			void _debug_log_pds(void);
-			void _debug_log_threads(void);
-
-		public:
-
-			/**
-			 * Constructor
-			 */
-			Platform_pd(Allocator &md_alloc, char const *name);
-
-			/**
-			 * Constructor used for core's PD
-			 */
-			Platform_pd(char const *name, signed pd_id);
-
-			/**
-			 * Destructor
-			 */
-			~Platform_pd();
-
-			/**
-			 * Register quota donation at allocator guard
-			 */
-			void upgrade_ram_quota(size_t) { }
-
-			/**
-			 * Initialize L4 task facility
-			 */
-			static void init();
-
-			/**
-			 * Bind thread to protection domain
-			 *
-			 * \return true on success
-			 */
-			bool bind_thread(Platform_thread &thread);
-
-			/**
-			 * Unbind thread from protection domain
-			 *
-			 * Free the thread's slot and update thread object.
-			 */
-			void unbind_thread(Platform_thread &thread);
- 
-			/**
-			 * Assign parent interface to protection domain
-			 */
-			void assign_parent(Native_capability) { }
-
-			int pd_id() const { return _pd_id; }
-
-
-			/*****************************
-			 ** Address-space interface **
-			 *****************************/
-
-			void flush(addr_t, size_t, Core_local_addr) override;
-	};
+	class Platform_pd;
 }
 
+
+class Genode::Platform_pd : public Address_space
+{
+	private:
+
+		/*
+		 * Noncopyable
+		 */
+		Platform_pd(Platform_pd const &);
+		Platform_pd &operator = (Platform_pd const &);
+
+		enum {
+			VERSION_BITS   = 10,
+			PD_FIRST       = 0x10,
+			PD_MAX         = (1 << 11) - 1, /* leave 0x7ff free for L4_INVALID_ID */
+			PD_VERSION_MAX = (1 << 10) - 1,
+			PD_INVALID     = -1,
+			THREAD_MAX     = (1 << 7),
+		};
+
+		unsigned _pd_id   = 0;
+		unsigned _version = 0;
+
+		Fiasco::l4_taskid_t _l4_task_id { };  /* L4 task ID */
+
+
+		/**********************************************
+		 ** Threads of this protection domain object **
+		 **********************************************/
+
+		Platform_thread *_threads[THREAD_MAX];
+
+		/**
+		 * Initialize thread allocator
+		 */
+		void _init_threads();
+
+		/**
+		 * Thread iteration for one task
+		 */
+		Platform_thread *_next_thread();
+
+		/**
+		 * Thread allocation
+		 *
+		 * Again a special case for Core thread0.
+		 */
+		int _alloc_thread(int thread_id, Platform_thread &thread);
+
+		/**
+		 * Thread deallocation
+		 *
+		 * No special case for Core thread0 here - we just never call it.
+		 */
+		void _free_thread(int thread_id);
+
+
+		/******************
+		 ** PD allocator **
+		 ******************/
+
+		struct Pd_alloc
+		{
+			unsigned reserved : 1;
+			unsigned free     : 1;
+			unsigned version  : VERSION_BITS;
+
+			Pd_alloc(bool r, bool f, unsigned v)
+			: reserved(r), free(f), version(v) { }
+
+			Pd_alloc() : reserved(0), free(0), version(0) { }
+		};
+
+		static Pd_alloc *_pds()
+		{
+			static Pd_alloc static_pds[PD_MAX];
+			return static_pds;
+		}
+
+		/**
+		 * Protection-domain creation
+		 *
+		 * The syscall parameter propagates if any L4 kernel function
+		 * should be used. We need the special case for the Core startup.
+		 */
+		void _create_pd(bool syscall);
+
+		/**
+		 * Protection domain destruction
+		 *
+		 * No special case for Core here - we just never call it.
+		 */
+		void _destroy_pd();
+
+		/**
+		 * Protection domain allocation
+		 *
+		 * Find free L4 task and use it. We need the special case for Core
+		 * startup.
+		 */
+		int _alloc_pd(signed pd_id);
+
+		/**
+		 * Protection domain deallocation
+		 *
+		 * No special case for Core here - we just never call it.
+		 */
+		void _free_pd();
+
+
+		/***************
+		 ** Debugging **
+		 ***************/
+
+		void _debug_log_pds(void);
+		void _debug_log_threads(void);
+
+	public:
+
+		/**
+		 * Constructor
+		 */
+		Platform_pd(Allocator &md_alloc, char const *name);
+
+		/**
+		 * Constructor used for core's PD
+		 */
+		Platform_pd(char const *name, signed pd_id);
+
+		/**
+		 * Destructor
+		 */
+		~Platform_pd();
+
+		/**
+		 * Register quota donation at allocator guard
+		 */
+		void upgrade_ram_quota(size_t) { }
+
+		/**
+		 * Initialize L4 task facility
+		 */
+		static void init();
+
+		/**
+		 * Bind thread to protection domain
+		 *
+		 * \return true on success
+		 */
+		bool bind_thread(Platform_thread &thread);
+
+		/**
+		 * Unbind thread from protection domain
+		 *
+		 * Free the thread's slot and update thread object.
+		 */
+		void unbind_thread(Platform_thread &thread);
+
+		/**
+		 * Assign parent interface to protection domain
+		 */
+		void assign_parent(Native_capability) { }
+
+		int pd_id() const { return _pd_id; }
+
+
+		/*****************************
+		 ** Address-space interface **
+		 *****************************/
+
+		void flush(addr_t, size_t, Core_local_addr) override;
+};
+
 #endif /* _CORE__INCLUDE__PLATFORM_PD_H_ */

repos/base-fiasco/src/core/include/platform_thread.h

@@ -24,167 +24,169 @@
 #include <platform_pd.h>
 #include <assertion.h>
 
-/* Fiasco includes */
-namespace Fiasco {
-#include <l4/sys/types.h>
-}
+/* L4/Fiasco includes */
+#include <fiasco/syscall.h>
 
 namespace Genode {
 
 	class Platform_pd;
-	class Platform_thread : Interface
-	{
-		private:
-
-			/*
-			 * Noncopyable
-			 */
-			Platform_thread(Platform_thread const &);
-			Platform_thread &operator = (Platform_thread const &);
-
-			int _thread_id = THREAD_INVALID;       /* plain thread number */
-
-			Fiasco::l4_threadid_t _l4_thread_id;
-
-			typedef String<32> Name;
-			Name const _name;                      /* thread name that will be
-			                                          registered at the kernel
-			                                          debugger */
-			Platform_pd *_platform_pd = nullptr;   /* protection domain thread
-			                                          is bound to */
-			Pager_object *_pager = nullptr;
-
-		public:
-
-			enum {
-				THREAD_INVALID = -1,  /* invalid thread number */
-			};
-
-			/**
-			 * Constructor
-			 */
-			Platform_thread(size_t, const char *name, unsigned priority,
-			                Affinity::Location, addr_t utcb);
-
-			/**
-			 * Constructor used for core-internal threads
-			 */
-			Platform_thread(const char *name);
-
-			/**
-			 * Destructor
-			 */
-			~Platform_thread();
-
-			/**
-			 * Start thread
-			 *
-			 * \param ip  instruction pointer to start at
-			 * \param sp  stack pointer to use
-			 *
-			 * \retval  0  successful
-			 * \retval -1  thread could not be started
-			 */
-			int start(void *ip, void *sp);
-
-			/**
-			 * Pause this thread
-			 */
-			void pause();
-
-			/**
-			 * Enable/disable single stepping
-			 */
-			void single_step(bool) { }
-
-			/**
-			 * Resume this thread
-			 */
-			void resume();
-
-			/**
-			 * This thread is about to be bound
-			 *
-			 * \param thread_id     local thread ID
-			 * \param l4_thread_id  final L4 thread ID
-			 * \param pd            platform pd, thread is bound to
-			 */
-			void bind(int thread_id, Fiasco::l4_threadid_t l4_thread_id,
-			          Platform_pd &pd);
-
-			/**
-			 * Unbind this thread
-			 */
-			void unbind();
-
-			/**
-			 * Override thread state with 's'
-			 *
-			 * \throw Cpu_session::State_access_failed
-			 */
-			void state(Thread_state s);
-
-			/**
-			 * Read thread state
-			 *
-			 * \throw Cpu_session::State_access_failed
-			 */
-			Thread_state state();
-
-			/**
-			 * Set the executing CPU for this thread
-			 *
-			 * SMP is not supported on L4/Fiasco.
-			 */
-			void affinity(Affinity::Location) { }
-
-			/**
-			 * Request the affinity of this thread
-			 */
-			Affinity::Location affinity() const { return Affinity::Location(); }
-
-			/************************
-			 ** Accessor functions **
-			 ************************/
-
-			/**
-			 * Return/set pager
-			 */
-			Pager_object &pager() const
-			{
-				if (_pager)
-					return *_pager;
-
-				ASSERT_NEVER_CALLED;
-			}
-
-			void pager(Pager_object &pager) { _pager = &pager; }
-
-			/**
-			 * Return identification of thread when faulting
-			 */
-			unsigned long pager_object_badge() const {
-				return convert_native_thread_id_to_badge(_l4_thread_id); }
-
-			/**
-			 * Set CPU quota of the thread to 'quota'
-			 */
-			void quota(size_t) { /* not supported*/ }
-
-			/**
-			 * Return execution time consumed by the thread
-			 */
-			Trace::Execution_time execution_time() const { return { 0, 0 }; }
-
-
-			/*******************************
-			 ** Fiasco-specific Accessors **
-			 *******************************/
-
-			int                   thread_id()        const { return _thread_id; }
-			Fiasco::l4_threadid_t native_thread_id() const { return _l4_thread_id; }
-			Name                  name()             const { return _name; }
-	};
+	class Platform_thread;
 }
 
+
+class Genode::Platform_thread : Interface
+{
+	private:
+
+		/*
+		 * Noncopyable
+		 */
+		Platform_thread(Platform_thread const &);
+		Platform_thread &operator = (Platform_thread const &);
+
+		int _thread_id = THREAD_INVALID;       /* plain thread number */
+
+		Fiasco::l4_threadid_t _l4_thread_id;
+
+		typedef String<32> Name;
+		Name const _name;                      /* thread name that will be
+		                                          registered at the kernel
+		                                          debugger */
+		Platform_pd *_platform_pd = nullptr;   /* protection domain thread
+		                                          is bound to */
+		Pager_object *_pager = nullptr;
+
+	public:
+
+		enum {
+			THREAD_INVALID = -1,  /* invalid thread number */
+		};
+
+		/**
+		 * Constructor
+		 */
+		Platform_thread(size_t, const char *name, unsigned priority,
+		                Affinity::Location, addr_t utcb);
+
+		/**
+		 * Constructor used for core-internal threads
+		 */
+		Platform_thread(const char *name);
+
+		/**
+		 * Destructor
+		 */
+		~Platform_thread();
+
+		/**
+		 * Start thread
+		 *
+		 * \param ip  instruction pointer to start at
+		 * \param sp  stack pointer to use
+		 *
+		 * \retval  0  successful
+		 * \retval -1  thread could not be started
+		 */
+		int start(void *ip, void *sp);
+
+		/**
+		 * Pause this thread
+		 */
+		void pause();
+
+		/**
+		 * Enable/disable single stepping
+		 */
+		void single_step(bool) { }
+
+		/**
+		 * Resume this thread
+		 */
+		void resume();
+
+		/**
+		 * This thread is about to be bound
+		 *
+		 * \param thread_id     local thread ID
+		 * \param l4_thread_id  final L4 thread ID
+		 * \param pd            platform pd, thread is bound to
+		 */
+		void bind(int thread_id, Fiasco::l4_threadid_t l4_thread_id,
+		          Platform_pd &pd);
+
+		/**
+		 * Unbind this thread
+		 */
+		void unbind();
+
+		/**
+		 * Override thread state with 's'
+		 *
+		 * \throw Cpu_session::State_access_failed
+		 */
+		void state(Thread_state s);
+
+		/**
+		 * Read thread state
+		 *
+		 * \throw Cpu_session::State_access_failed
+		 */
+		Thread_state state();
+
+		/**
+		 * Set the executing CPU for this thread
+		 *
+		 * SMP is not supported on L4/Fiasco.
+		 */
+		void affinity(Affinity::Location) { }
+
+		/**
+		 * Request the affinity of this thread
+		 */
+		Affinity::Location affinity() const { return Affinity::Location(); }
+
+
+		/************************
+		 ** Accessor functions **
+		 ************************/
+
+		/**
+		 * Return/set pager
+		 */
+		Pager_object &pager() const
+		{
+			if (_pager)
+				return *_pager;
+
+			ASSERT_NEVER_CALLED;
+		}
+
+		void pager(Pager_object &pager) { _pager = &pager; }
+
+		/**
+		 * Return identification of thread when faulting
+		 */
+		unsigned long pager_object_badge() const {
+			return convert_native_thread_id_to_badge(_l4_thread_id); }
+
+		/**
+		 * Set CPU quota of the thread to 'quota'
+		 */
+		void quota(size_t) { /* not supported*/ }
+
+		/**
+		 * Return execution time consumed by the thread
+		 */
+		Trace::Execution_time execution_time() const { return { 0, 0 }; }
+
+
+		/*******************************
+		 ** Fiasco-specific Accessors **
+		 *******************************/
+
+		int                   thread_id()        const { return _thread_id; }
+		Fiasco::l4_threadid_t native_thread_id() const { return _l4_thread_id; }
+		Name                  name()             const { return _name; }
+};
+
 #endif /* _CORE__INCLUDE__PLATFORM_THREAD_H_ */

repos/base-fiasco/src/core/include/rpc_cap_factory.h

@@ -14,11 +14,13 @@
 #ifndef _CORE__INCLUDE__RPC_CAP_FACTORY_H_
 #define _CORE__INCLUDE__RPC_CAP_FACTORY_H_
 
+/* Genode includes */
 #include <base/allocator.h>
 #include <base/capability.h>
 
 namespace Genode { class Rpc_cap_factory; }
 
+
 class Genode::Rpc_cap_factory
 {
 	private:

repos/base-fiasco/src/core/include/util.h

@@ -25,13 +25,8 @@
 #include <base/internal/fiasco_thread_helper.h>
 #include <base/internal/page_size.h>
 
-/* Fiasco includes */
-namespace Fiasco {
-#include <l4/sys/types.h>
-#include <l4/sys/ipc.h>
-#include <l4/sys/kdebug.h>
-#include <l4/sys/ktrace.h>
-}
+/* L4/Fiasco includes */
+#include <fiasco/syscall.h>
 
 namespace Genode {
 

repos/base-fiasco/src/core/io_mem_session_support.cc

@@ -16,11 +16,8 @@
 #include <util.h>
 #include <io_mem_session_component.h>
 
-/* Fiasco includes */
-namespace Fiasco {
-#include <l4/sys/ipc.h>
-#include <l4/sigma0/sigma0.h>
-}
+/* L4/Fiasco includes */
+#include <fiasco/syscall.h>
 
 using namespace Genode;
 

repos/base-fiasco/src/core/irq_session_component.cc

@@ -19,15 +19,12 @@
 #include <irq_root.h>
 #include <util.h>
 
-/* Fiasco includes */
-namespace Fiasco {
-#include <l4/sys/ipc.h>
-#include <l4/sys/syscalls.h>
-#include <l4/sys/types.h>
-}
+/* L4/Fiasco includes */
+#include <fiasco/syscall.h>
 
 using namespace Genode;
 
+
 bool Irq_object::_associate()
 {
 	using namespace Fiasco;
@@ -74,7 +71,9 @@ void Irq_object::_wait_for_irq()
 		            L4_IPC_SHORT_MSG, &dw0, &dw1,
 		            L4_IPC_NEVER, &result);
 
-		if (L4_IPC_IS_ERROR(result)) error("Ipc error ", L4_IPC_ERROR(result));
+		if (L4_IPC_IS_ERROR(result))
+			error("Ipc error ", L4_IPC_ERROR(result));
+
 	} while (L4_IPC_IS_ERROR(result));
 }
 
@@ -106,7 +105,7 @@ void Irq_object::entry()
 		if (!_sig_cap.valid())
 			continue;
 
-		Genode::Signal_transmitter(_sig_cap).submit(1);
+		Signal_transmitter(_sig_cap).submit(1);
 
 		_sync_ack.block();
 	}
@@ -115,7 +114,7 @@ void Irq_object::entry()
 
 Irq_object::Irq_object(unsigned irq)
 :
-	Thread_deprecated<4096>("irq"),
+	Thread(Weight::DEFAULT_WEIGHT, "irq", 4096 /* stack */, Type::NORMAL),
 	_irq(irq)
 { }
 
@@ -142,7 +141,7 @@ Irq_session_component::Irq_session_component(Range_allocator &irq_alloc,
 
 Irq_session_component::~Irq_session_component()
 {
-	error("Not yet implemented.");
+	error(__func__, " - not implemented");
 }
 
 
@@ -152,13 +151,13 @@ void Irq_session_component::ack_irq()
 }
 
 
-void Irq_session_component::sigh(Genode::Signal_context_capability cap)
+void Irq_session_component::sigh(Signal_context_capability cap)
 {
 	_irq_object.sigh(cap);
 }
 
 
-Genode::Irq_session::Info Irq_session_component::info()
+Irq_session::Info Irq_session_component::info()
 {
 	/* no MSI support */
 	return { .type = Info::Type::INVALID, .address = 0, .value = 0 };

repos/base-fiasco/src/core/pager.cc

@@ -22,10 +22,8 @@
 #include <base/internal/native_thread.h>
 #include <base/internal/capability_space_tpl.h>
 
-namespace Fiasco {
-#include <l4/sys/ipc.h>
-#include <l4/sys/syscalls.h>
-}
+/* L4/Fiasco includes */
+#include <fiasco/syscall.h>
 
 using namespace Genode;
 using namespace Fiasco;
@@ -37,7 +35,7 @@ using namespace Fiasco;
 
 void Ipc_pager::wait_for_fault()
 {
-	l4_msgdope_t  result;
+	l4_msgdope_t result;
 
 	do {
 		l4_ipc_wait(&_last,
@@ -53,7 +51,7 @@ void Ipc_pager::wait_for_fault()
 
 void Ipc_pager::reply_and_wait_for_fault()
 {
-	l4_msgdope_t  result;
+	l4_msgdope_t result;
 
 	l4_ipc_reply_and_wait(_last,
 	                      L4_IPC_SHORT_FPAGE, _reply_mapping.dst_addr(),

repos/base-fiasco/src/core/pager_object.cc

@@ -17,12 +17,8 @@
 /* base-internal includes */
 #include <base/internal/capability_space_tpl.h>
 
-/* Fiasco includes */
-namespace Fiasco {
-#include <l4/sys/ipc.h>
-#include <l4/sys/syscalls.h>
-#include <l4/sys/kdebug.h>
-}
+/* L4/Fiasco includes */
+#include <fiasco/syscall.h>
 
 using namespace Genode;
 

repos/base-fiasco/src/core/platform.cc

@@ -31,17 +31,11 @@
 #include <platform_pd.h>
 #include <util.h>
 
-/* Fiasco includes */
-namespace Fiasco {
-#include <l4/sys/types.h>
-#include <l4/sys/syscalls.h>
-#include <l4/sys/ipc.h>
-#include <l4/sys/kernel.h>
-#include <l4/sys/kip.h>
-#include <l4/sigma0/sigma0.h>
-}
+/* L4/Fiasco includes */
+#include <fiasco/syscall.h>
 
 using namespace Genode;
+using namespace Fiasco;
 
 
 /***********************************
@@ -54,6 +48,7 @@ static Synced_range_allocator<Allocator_avl> &_core_address_ranges()
 	return _core_address_ranges;
 }
 
+
 enum { PAGER_STACK_ELEMENTS = 1024 };
 static unsigned long _core_pager_stack[PAGER_STACK_ELEMENTS];
 static unsigned _core_pager_arg;
@@ -66,8 +61,6 @@ static void _core_pager_loop()
 {
 	unsigned pd_id = _core_pager_arg;
 
-	using namespace Fiasco;
-
 	l4_threadid_t t;
 	l4_umword_t dw0, dw1;
 	l4_msgdope_t r;
@@ -136,7 +129,7 @@ Platform::Sigma0::Sigma0()
 	             0, Affinity::Location(), Session_label(),
 	             Cpu_session::Name("sigma0"))
 {
-	cap(Capability_space::import(Fiasco::sigma0_threadid, Rpc_obj_key()));
+	cap(Capability_space::import(sigma0_threadid, Rpc_obj_key()));
 }
 
 
@@ -166,8 +159,6 @@ Platform::Core_pager::Core_pager(Platform_pd &core_pd)
 	void *sp = (void *)&_core_pager_stack[PAGER_STACK_ELEMENTS - 1];
 	start((void *)_core_pager_loop, sp);
 
-	using namespace Fiasco;
-
 	/* pager0 receives pagefaults from me - for NULL pointer detection */
 	l4_umword_t d;
 	l4_threadid_t preempter = L4_INVALID_ID;
@@ -236,8 +227,6 @@ static inline void remove_region(Region r, Range_allocator &alloc)
  */
 static inline int sigma0_req_region(addr_t *addr, unsigned log2size)
 {
-	using namespace Fiasco;
-
 	/* XXX sigma0 always maps pages RW */
 	l4_umword_t req_fpage = l4_fpage(0, log2size, 0, 0).fpage;
 	void* rcv_window = L4_IPC_MAPMSG(0, L4_WHOLE_ADDRESS_SPACE);
@@ -246,7 +235,7 @@ static inline int sigma0_req_region(addr_t *addr, unsigned log2size)
 	l4_msgdope_t result;
 	l4_msgtag_t tag;
 
-	int err = l4_ipc_call_tag(Fiasco::sigma0_threadid,
+	int err = l4_ipc_call_tag(sigma0_threadid,
 	                          L4_IPC_SHORT_MSG, SIGMA0_REQ_FPAGE_ANY, req_fpage,
 	                          l4_msgtag(L4_MSGTAG_SIGMA0, 0, 0, 0),
 	                          rcv_window, &base, (l4_umword_t *)&rcv_fpage,
@@ -288,8 +277,8 @@ void Platform::_setup_mem_alloc()
 			if (!err) {
 				/* XXX do not allocate page0 */
 				if (addr == 0) {
-					Fiasco::l4_fpage_unmap(Fiasco::l4_fpage(0, log2_size, 0, 0),
-					                       L4_FP_FLUSH_PAGE | L4_FP_ALL_SPACES);
+					l4_fpage_unmap(l4_fpage(0, log2_size, 0, 0),
+					               L4_FP_FLUSH_PAGE | L4_FP_ALL_SPACES);
 					continue;
 				}
 
@@ -307,14 +296,14 @@ void Platform::_setup_mem_alloc()
 }
 
 
-void Platform::_setup_irq_alloc() {
-	_irq_alloc.add_range(0, 0x10); }
-
-
-static Fiasco::l4_kernel_info_t *get_kip()
+void Platform::_setup_irq_alloc()
 {
-	using namespace Fiasco;
+	_irq_alloc.add_range(0, 0x10);
+}
 
+
+static l4_kernel_info_t *get_kip()
+{
 	static l4_kernel_info_t *kip = nullptr;
 
 	if (kip) return kip;
@@ -329,7 +318,7 @@ static Fiasco::l4_kernel_info_t *get_kip()
 	l4_msgdope_t r;
 	l4_msgtag_t tag;
 
-	err = l4_ipc_call_tag(Fiasco::sigma0_threadid,
+	err = l4_ipc_call_tag(sigma0_threadid,
 	                      L4_IPC_SHORT_MSG, SIGMA0_REQ_KIP, 0,
 	                      l4_msgtag(L4_MSGTAG_SIGMA0, 0, 0, 0),
 	                      fpage, &dw0, &dw1,
@@ -357,10 +346,9 @@ static Fiasco::l4_kernel_info_t *get_kip()
 	return kip;
 }
 
+
 void Platform::_setup_basics()
 {
-	using namespace Fiasco;
-
 	l4_kernel_info_t * kip = get_kip();
 
 	/* add KIP as ROM module */
@@ -380,6 +368,7 @@ void Platform::_setup_basics()
 
 			break;
 		}
+
 	if (_vm_size == 0)
 		panic("Virtual memory configuration not found");
 
@@ -411,7 +400,8 @@ void Platform::_setup_basics()
 }
 
 
-Platform::Platform() :
+Platform::Platform()
+:
 	_ram_alloc(nullptr), _io_mem_alloc(&core_mem_alloc()),
 	_io_port_alloc(&core_mem_alloc()), _irq_alloc(&core_mem_alloc()),
 	_region_alloc(&core_mem_alloc()),
@@ -432,7 +422,7 @@ Platform::Platform() :
 
 	log(_rom_fs);
 
-	Fiasco::l4_threadid_t myself = Fiasco::l4_myself();
+	l4_threadid_t myself = l4_myself();
 
 	Platform_pd::init();
 
@@ -451,8 +441,8 @@ Platform::Platform() :
 	_core_pd->bind_thread(core_thread);
 
 	/* we never call _core_thread.start(), so set name directly */
-	Fiasco::fiasco_register_thread_name(core_thread.native_thread_id(),
-	                                    core_thread.name().string());
+	fiasco_register_thread_name(core_thread.native_thread_id(),
+	                            core_thread.name().string());
 
 	/* core log as ROM module */
 	{

repos/base-fiasco/src/core/platform_pd.cc

@@ -25,19 +25,13 @@
 #include <util.h>
 #include <platform_pd.h>
 
-/* Fiasco includes */
-namespace Fiasco {
-#include <l4/sys/syscalls.h>
-}
+/* L4/Fiasco includes */
+#include <fiasco/syscall.h>
 
 using namespace Fiasco;
 using namespace Genode;
 
 
-/**************************
- ** Static class members **
- **************************/
-
 static bool _init = false;
 
 
@@ -64,10 +58,10 @@ void Platform_pd::init()
 
 void Platform_pd::_create_pd(bool syscall)
 {
-	l4_threadid_t l4t   = l4_myself();
-	l4t.id.task         = _pd_id;
-	l4t.id.lthread      = 0;
-	l4t.id.version_low  = _version;
+	l4_threadid_t l4t  = l4_myself();
+	l4t.id.task        = _pd_id;
+	l4t.id.lthread     = 0;
+	l4t.id.version_low = _version;
 
 	l4_taskid_t nt;
 	if (syscall)

repos/base-fiasco/src/core/platform_thread.cc

@@ -25,13 +25,8 @@
 /* base-internal includes */
 #include <base/internal/capability_space_tpl.h>
 
-/* Fiasco includes */
-namespace Fiasco {
-#include <l4/sys/types.h>
-#include <l4/sys/syscalls.h>
-#include <l4/sys/utcb.h>
-#include <l4/sys/kdebug.h>
-}
+/* L4/Fiasco includes */
+#include <fiasco/syscall.h>
 
 using namespace Genode;
 using namespace Fiasco;

repos/base-fiasco/src/core/ram_dataspace_support.cc

@@ -14,13 +14,18 @@
  * under the terms of the GNU Affero General Public License version 3.
  */
 
+/* core includes */
 #include <ram_dataspace_factory.h>
 
 using namespace Genode;
 
+
 void Ram_dataspace_factory::_export_ram_ds(Dataspace_component &) { }
+
+
 void Ram_dataspace_factory::_revoke_ram_ds(Dataspace_component &) { }
 
+
 void Ram_dataspace_factory::_clear_ds(Dataspace_component &ds)
 {
 	memset((void *)ds.phys_addr(), 0, ds.size());

repos/base-fiasco/src/core/spec/x86/platform_x86.cc

@@ -11,18 +11,20 @@
  * under the terms of the GNU Affero General Public License version 3.
  */
 
+/* base-internal includes */
 #include <base/internal/fiasco_thread_helper.h>
 
-#include "platform.h"
-#include "util.h"
+/* core includes */
+#include <platform.h>
+#include <util.h>
 
-namespace Fiasco {
-#include <l4/sys/ipc.h>
-}
+/* L4/Fiasco includes */
+#include <fiasco/syscall.h>
 
 using namespace Genode;
 using namespace Fiasco;
 
+
 void Platform::_setup_io_port_alloc()
 {
 	l4_fpage_t fp;

repos/base-fiasco/src/include/base/internal/fiasco_thread_helper.h

@@ -14,8 +14,10 @@
 #ifndef _INCLUDE__FIASCO__THREAD_HELPER_H_
 #define _INCLUDE__FIASCO__THREAD_HELPER_H_
 
+/* L4/Fiasco includes */
+#include <fiasco/syscall.h>
+
 namespace Fiasco {
-#include <l4/sys/types.h>
 
 	/**
 	 * Sigma0 thread ID

repos/base-fiasco/src/include/base/internal/lock_helper.h

@@ -22,9 +22,7 @@
 #define _INCLUDE__BASE__INTERNAL__LOCK_HELPER_H_
 
 /* L4/Fiasco includes */
-namespace Fiasco {
-#include <l4/sys/ipc.h>
-}
+#include <fiasco/syscall.h>
 
 
 /**

repos/base-fiasco/src/include/base/internal/native_thread.h

@@ -17,10 +17,8 @@
 /* Genode includes */
 #include <base/stdint.h>
 
-/* Fiasco includes */
-namespace Fiasco {
-#include <l4/sys/types.h>
-}
+/* L4/Fiasco includes */
+#include <fiasco/syscall.h>
 
 namespace Genode {
 
@@ -28,6 +26,7 @@ namespace Genode {
 	struct Native_thread;
 }
 
+
 struct Genode::Native_thread
 {
 	Fiasco::l4_threadid_t l4id;

repos/base-fiasco/src/include/base/internal/raw_write_string.h

@@ -14,10 +14,8 @@
 #ifndef _INCLUDE__BASE__INTERNAL__RAW_WRITE_STRING_H_
 #define _INCLUDE__BASE__INTERNAL__RAW_WRITE_STRING_H_
 
-/* Fiasco includes */
-namespace Fiasco {
-#include <l4/sys/kdebug.h>
-}
+/* L4/Fiasco includes */
+#include <fiasco/syscall.h>
 
 namespace Genode {
 

repos/base-fiasco/src/include/base/internal/rpc_destination.h

@@ -14,10 +14,8 @@
 #ifndef _INCLUDE__BASE__INTERNAL__RPC_DESTINATION_H_
 #define _INCLUDE__BASE__INTERNAL__RPC_DESTINATION_H_
 
-/* Fiasco includes */
-namespace Fiasco {
-#include <l4/sys/types.h>
-}
+/* L4/Fiasco includes */
+#include <fiasco/syscall.h>
 
 namespace Genode {
 

repos/base-fiasco/src/include/fiasco/syscall.h

@@ -0,0 +1,29 @@
+/*
+ * \brief  Collection of L4/Fiasco kernel bindings
+ * \author Norman Feske
+ * \date   2020-12-06
+ */
+
+/*
+ * Copyright (C) 2020 Genode Labs GmbH
+ *
+ * This file is part of the Genode OS framework, which is distributed
+ * under the terms of the GNU Affero General Public License version 3.
+ */
+
+#ifndef _INCLUDE__FIASCO__SYSCALL_H_
+#define _INCLUDE__FIASCO__SYSCALL_H_
+
+namespace Fiasco {
+#include <l4/sys/types.h>
+#include <l4/sys/kdebug.h>
+#include <l4/sys/ipc.h>
+#include <l4/sys/kernel.h>
+#include <l4/sys/kip.h>
+#include <l4/sys/utcb.h>
+#include <l4/sys/ktrace.h>
+#include <l4/sys/syscalls.h>
+#include <l4/sigma0/sigma0.h>
+}
+
+#endif /* _INCLUDE__FIASCO__SYSCALL_H_ */

repos/base-fiasco/src/lib/base/capability_raw.cc

@@ -11,6 +11,7 @@
  * under the terms of the GNU Affero General Public License version 3.
  */
 
+/* Genode includes */
 #include <base/log.h>
 
 /* base-internal includes */

repos/base-fiasco/src/lib/base/ipc.cc

@@ -20,13 +20,11 @@
 #include <base/internal/ipc_server.h>
 #include <base/internal/capability_space_tpl.h>
 
-/* Fiasco includes */
-namespace Fiasco {
-#include <l4/sys/ipc.h>
-#include <l4/sys/syscalls.h>
-}
+/* L4/Fiasco includes */
+#include <fiasco/syscall.h>
 
 using namespace Genode;
+using namespace Fiasco;
 
 
 class Msg_header
@@ -34,9 +32,9 @@ class Msg_header
 	private:
 
 		/* kernel-defined message header */
-		Fiasco::l4_fpage_t   rcv_fpage; /* unused */
-		Fiasco::l4_msgdope_t size_dope;
-		Fiasco::l4_msgdope_t send_dope;
+		l4_fpage_t   rcv_fpage; /* unused */
+		l4_msgdope_t size_dope;
+		l4_msgdope_t send_dope;
 
 	public:
 
@@ -47,15 +45,15 @@ class Msg_header
 		 * arguments. The kernel does not fetch these data words from memory
 		 * but transfers them via the short-IPC registers.
 		 */
-		Fiasco::l4_umword_t protocol_word;
-		Fiasco::l4_umword_t num_caps;
+		l4_umword_t protocol_word;
+		l4_umword_t num_caps;
 
 	private:
 
 		enum { MAX_CAPS_PER_MSG = Msgbuf_base::MAX_CAPS_PER_MSG };
 
-		Fiasco::l4_threadid_t _cap_tid        [MAX_CAPS_PER_MSG];
-		unsigned long         _cap_local_name [MAX_CAPS_PER_MSG];
+		l4_threadid_t _cap_tid        [MAX_CAPS_PER_MSG];
+		unsigned long _cap_local_name [MAX_CAPS_PER_MSG];
 
 		size_t _num_msg_words(size_t num_data_words) const
 		{
@@ -65,7 +63,7 @@ class Msg_header
 			 * Account for the transfer of the protocol word, capability count,
 			 * and capability arguments in front of the payload.
 			 */
-			return 2 + caps_size/sizeof(Fiasco::l4_umword_t) + num_data_words;
+			return 2 + caps_size/sizeof(l4_umword_t) + num_data_words;
 		}
 
 	public:
@@ -77,8 +75,6 @@ class Msg_header
 		 */
 		void prepare_snd_msg(unsigned long protocol, Msgbuf_base const &snd_msg)
 		{
-			using namespace Fiasco;
-
 			protocol_word = protocol;
 			num_caps = min((unsigned)MAX_CAPS_PER_MSG, snd_msg.used_caps());
 
@@ -109,8 +105,6 @@ class Msg_header
 		 */
 		void prepare_rcv_msg(Msgbuf_base const &rcv_msg)
 		{
-			using namespace Fiasco;
-
 			size_t const rcv_max_words = rcv_msg.capacity()/sizeof(l4_umword_t);
 
 			size_dope = L4_IPC_DOPE(_num_msg_words(rcv_max_words), 0);
@@ -124,7 +118,7 @@ class Msg_header
 			for (unsigned i = 0; i < min((unsigned)MAX_CAPS_PER_MSG, num_caps); i++) {
 
 				Rpc_obj_key const rpc_obj_key(_cap_local_name[i]);
-				bool        const cap_valid = !Fiasco::l4_is_invalid_id(_cap_tid[i]);
+				bool        const cap_valid = !l4_is_invalid_id(_cap_tid[i]);
 
 				Native_capability cap;
 				if (cap_valid) {
@@ -147,8 +141,6 @@ Rpc_exception_code Genode::ipc_call(Native_capability dst,
                                     Msgbuf_base &snd_msg, Msgbuf_base &rcv_msg,
                                     size_t)
 {
-	using namespace Fiasco;
-
 	Capability_space::Ipc_cap_data const dst_data =
 		Capability_space::ipc_cap_data(dst);
 
@@ -190,8 +182,6 @@ Rpc_exception_code Genode::ipc_call(Native_capability dst,
 void Genode::ipc_reply(Native_capability caller, Rpc_exception_code exc,
                        Msgbuf_base &snd_msg)
 {
-	using namespace Fiasco;
-
 	Msg_header &snd_header = snd_msg.header<Msg_header>();
 	snd_header.prepare_snd_msg(exc.value, snd_msg);
 
@@ -209,8 +199,6 @@ Genode::Rpc_request Genode::ipc_reply_wait(Reply_capability const &last_caller,
                                            Msgbuf_base            &reply_msg,
                                            Msgbuf_base            &request_msg)
 {
-	using namespace Fiasco;
-
 	l4_msgdope_t ipc_result;
 
 	bool need_to_wait = true;
@@ -276,7 +264,7 @@ Genode::Rpc_request Genode::ipc_reply_wait(Reply_capability const &last_caller,
 
 Ipc_server::Ipc_server()
 :
-	Native_capability(Capability_space::import(Fiasco::l4_myself(), Rpc_obj_key()))
+	Native_capability(Capability_space::import(l4_myself(), Rpc_obj_key()))
 { }
 
 

repos/base-fiasco/src/lib/base/lock.cc

@@ -17,15 +17,14 @@
 #include <cpu/memory_barrier.h>
 
 /* L4/Fiasco includes */
-namespace Fiasco {
-#include <l4/sys/ipc.h>
-}
+#include <fiasco/syscall.h>
 
 using namespace Genode;
 
 
 Lock::Lock(Lock::State initial)
-: _state(UNLOCKED), _owner(nullptr)
+:
+	_state(UNLOCKED), _owner(nullptr)
 {
 	if (initial == LOCKED)
 		lock();
@@ -45,7 +44,7 @@ void Lock::lock(Applicant &myself)
 	 * XXX: How to notice cancel-blocking signals issued when  being outside the
 	 *      'l4_ipc_sleep' system call?
 	 */
-	while (!Genode::cmpxchg(&_state, UNLOCKED, LOCKED))
+	while (!cmpxchg(&_state, UNLOCKED, LOCKED))
 		Fiasco::l4_ipc_sleep(Fiasco::l4_ipc_timeout(0, 0, 500, 0));
 
 	_owner = myself;
@@ -55,6 +54,6 @@ void Lock::lock(Applicant &myself)
 void Lock::unlock()
 {
 	_owner = Applicant(nullptr);
-	Genode::memory_barrier();
+	memory_barrier();
 	_state = UNLOCKED;
 }

repos/base-fiasco/src/lib/base/sleep.cc

@@ -16,9 +16,7 @@
 #include <base/sleep.h>
 
 /* L4/Fiasco includes */
-namespace Fiasco {
-#include <l4/sys/ipc.h>
-}
+#include <fiasco/syscall.h>
 
 
 void Genode::sleep_forever()

repos/base-foc/README

@@ -1,9 +1,4 @@
 This repository contains the port of Genode to the Fiasco.OC microkernel.
-For further information, please refer to the following documents:
 
-:[http://genode.org/community/wiki/GenodeOnFiascoOC - Genode on Fiasco.OC Wiki page]:
-  This Wiki page contains the information on how to build and use
-  Genode with Fiasco.OC.
-
-:[http://os.inf.tu-dresden.de/fiasco]:
-  Official website for the Fiasco.OC microkernel.
+:[https://os.inf.tu-dresden.de/fiasco]:
+  Official website for the Fiasco.OC microkernel

repos/base-foc/etc/board.conf

@@ -0,0 +1 @@
+BOARD ?= unknown

repos/base-foc/etc/specs.conf

@@ -1,5 +1 @@
 SPECS += foc
-
-ifneq ($(filter x86_%,$(SPECS)),)
-SPECS += pci acpi ps2 vesa framebuffer
-endif

repos/base-foc/include/foc/capability_space.h

@@ -25,17 +25,17 @@ namespace Genode { namespace Capability_space {
 	 * Allocate kernel capability selector without associating it with a
 	 * Genode capability
 	 */
-	Fiasco::l4_cap_idx_t alloc_kcap();
+	Foc::l4_cap_idx_t alloc_kcap();
 
 	/**
 	 * Release kernel capability selector
 	 */
-	void free_kcap(Fiasco::l4_cap_idx_t);
+	void free_kcap(Foc::l4_cap_idx_t);
 
 	/**
 	 * Request kernel capability selector associated with Genode capability
 	 */
-	Fiasco::l4_cap_idx_t kcap(Native_capability);
+	Foc::l4_cap_idx_t kcap(Native_capability);
 
 } }
 

repos/base-foc/include/foc/native_capability.h

@@ -14,18 +14,16 @@
 #ifndef _INCLUDE__FOC__NATIVE_CAPABILITY_H_
 #define _INCLUDE__FOC__NATIVE_CAPABILITY_H_
 
-namespace Fiasco {
-#include <l4/sys/consts.h>
-#include <l4/sys/types.h>
-#include <l4/sys/utcb.h>
-#include <l4/sys/task.h>
+#include <foc/syscall.h>
+
+namespace Foc {
 
 	/*********************************************
 	 ** Capability selectors controlled by core **
 	 *********************************************/
 
 	/* use the same task cap selector like L4Re for compatibility in L4Linux */
-	static constexpr l4_cap_idx_t TASK_CAP = L4_BASE_TASK_CAP;
+	static constexpr l4_cap_idx_t TASK_CAP  = L4_BASE_TASK_CAP;
 
 	static constexpr l4_cap_idx_t DEBUG_CAP = L4_BASE_DEBUGGER_CAP;
 

repos/base-foc/include/foc/native_thread.h

@@ -21,23 +21,20 @@
 /* Genode includes */
 #include <base/stdint.h>
 #include <foc/receive_window.h>
-
-/* Fiasco.OC includes */
-namespace Fiasco {
-#include <l4/sys/types.h>
-}
+#include <foc/syscall.h>
 
 namespace Genode { struct Native_thread; }
 
+
 struct Genode::Native_thread
 {
-	Fiasco::l4_cap_idx_t kcap = 0;
+	Foc::l4_cap_idx_t kcap = 0;
 
 	/* receive window for capability selectors received at the server side */
 	Receive_window rcv_window { };
 
 	Native_thread() { }
-	explicit Native_thread(Fiasco::l4_cap_idx_t kcap) : kcap(kcap) { }
+	explicit Native_thread(Foc::l4_cap_idx_t kcap) : kcap(kcap) { }
 };
 
 #endif /* _INCLUDE__FOC__NATIVE_THREAD_H_ */

repos/base-foc/include/foc/syscall.h

@@ -0,0 +1,36 @@
+/*
+ * \brief  Collection of Fiasco.OC kernel bindings
+ * \author Norman Feske
+ * \date   2020-11-27
+ */
+
+/*
+ * Copyright (C) 2020 Genode Labs GmbH
+ *
+ * This file is part of the Genode OS framework, which is distributed
+ * under the terms of the GNU Affero General Public License version 3.
+ */
+
+#ifndef _INCLUDE__FOC__SYSCALL_H_
+#define _INCLUDE__FOC__SYSCALL_H_
+
+namespace Foc {
+#include <l4/sys/types.h>
+#include <l4/sys/kip>
+#include <l4/sys/kdebug.h>
+#include <l4/sys/cache.h>
+#include <l4/sys/consts.h>
+#include <l4/sys/utcb.h>
+#include <l4/sys/task.h>
+#include <l4/sys/ipc.h>
+#include <l4/sys/thread.h>
+#include <l4/sys/factory.h>
+#include <l4/sys/irq.h>
+#include <l4/sys/debugger.h>
+#include <l4/sys/icu.h>
+#include <l4/sys/ktrace.h>
+#include <l4/sys/scheduler.h>
+#include <l4/sigma0/sigma0.h>
+}
+
+#endif /* _INCLUDE__FOC__SYSCALL_H_ */

repos/base-foc/include/foc/thread_state.h

@@ -18,25 +18,21 @@
 
 #include <base/capability.h>
 #include <base/thread_state.h>
-
-/* Fiasco includes */
-namespace Fiasco {
-#include <l4/sys/types.h>
-}
+#include <foc/syscall.h>
 
 namespace Genode { struct Foc_thread_state; }
 
 
 struct Genode::Foc_thread_state : Thread_state
 {
-	Fiasco::l4_cap_idx_t  kcap;         /* thread's gate cap in its pd */
-	int                   id;           /* id of gate capability */
-	addr_t                utcb;         /* thread's utcb in its pd */
+	Foc::l4_cap_idx_t  kcap;         /* thread's gate cap in its PD */
+	int                id;           /* ID of gate capability */
+	addr_t             utcb;         /* thread's UTCB in its PD */
 
 	/**
 	 * Constructor
 	 */
-	Foc_thread_state() : kcap(Fiasco::L4_INVALID_CAP), id(0), utcb(0) { }
+	Foc_thread_state() : kcap(Foc::L4_INVALID_CAP), id(0), utcb(0) { }
 };
 
 #endif /* _INCLUDE__FOC__THREAD_STATE_H_ */

repos/base-foc/include/foc_native_cpu/client.h

@@ -21,10 +21,10 @@
 namespace Genode { struct Foc_native_cpu_client; }
 
 
-struct Genode::Foc_native_cpu_client : Rpc_client<Foc_native_cpu>
+struct Genode::Foc_native_cpu_client : Rpc_client<Cpu_session::Native_cpu>
 {
 	explicit Foc_native_cpu_client(Capability<Native_cpu> cap)
-	: Rpc_client<Foc_native_cpu>(static_cap_cast<Foc_native_cpu>(cap)) { }
+	: Rpc_client<Cpu_session::Native_cpu>(cap) { }
 
 	Native_capability native_cap(Thread_capability cap) override {
 		return call<Rpc_native_cap>(cap); }

repos/base-foc/include/foc_native_cpu/foc_native_cpu.h

@@ -19,10 +19,8 @@
 #include <cpu_session/cpu_session.h>
 #include <foc/thread_state.h>
 
-namespace Genode { struct Foc_native_cpu; }
 
-
-struct Genode::Foc_native_cpu : Cpu_session::Native_cpu
+struct Genode::Cpu_session::Native_cpu : Interface
 {
 	virtual Native_capability native_cap(Thread_capability) = 0;
 	virtual Foc_thread_state thread_state(Thread_capability) = 0;