From 4f1a3a80006bcfdbbffd9bddfebf100562862b94 Mon Sep 17 00:00:00 2001 From: Norman Feske Date: Mon, 22 Feb 2021 16:49:09 +0100 Subject: [PATCH] Release notes for version 21.02 --- doc/release_notes/21-02.txt | 663 ++++++++++++++++++++++++++++++++++++ 1 file changed, 663 insertions(+) create mode 100644 doc/release_notes/21-02.txt diff --git a/doc/release_notes/21-02.txt b/doc/release_notes/21-02.txt new file mode 100644 index 0000000000..681757122f --- /dev/null +++ b/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 '' tags in the configuration are now simply applied to both +session types. This means, that each '' tag that connected a driver in a +router configuration can now be replaced by a '' 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_ -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 ''. +# 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 '' 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 '' is set in the router's config. A router +report with multiple DNS server entries will look like this: + +! +! +! +! +! +! ... +! +! +! +! +! ... +! +! ... +! + +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: + +! +! +! + +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: + +! +! +! +! +! +! +! + +The order of the '' 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 '' tag +is no longer considered by the router as the new '' 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 '' sub node to the '' node +of the 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. + +! +! +! ... +! + +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 '. +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 +_/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//arch_ files. The attempt to +build a base-hw- 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 +