NOVA is a modern open-source (GPLv2) microhypervisor that can host and harden unmodified guest operating systems. NOVA is typically accompanied by a component-based OS that runs deprivileged and implements additional functionality, such as platform services and user-mode device drivers.
Over the years, the interrupt subsystem of modern client and server platforms has evolved significantly, by (1) scaling up from only a few pin-based to thousands of message-signaled interrupts and (2) scaling out the delivery of those interrupts across dozens or hundreds of CPU cores.
Architectural differences between ARMv8-A and x86_64, such as
pose a challenge to the design of a uniform API for managing interrupts and devices and motivated the introduction of a new type of kernel object in NOVA: Device Contexts
After a brief discussion of NOVA features added recently, the majority of the talk will focus on NOVA's new interfaces for managing hardware devices and interrupts.
Links:
This talk gives an overview of skiftOS’s architecture, focusing on its microkernel core and service model. It explores the design trade-offs behind keeping the kernel minimal yet practical, and the lessons learned from building a complete, usable operating system on top of it.
The session is aimed at developers interested in microkernels, operating system internals, and the challenges of scaling a small core into a functional ecosystem.
Project Repo: https://github.com/skift-org/skift
The Genode OS Framework is certainly not a newcomer but still under very active development. While the framework supports various third-party microkernels, its custom-tailored base-hw kernel has proven valuable for putting Genode-specific (kernel) concepts to the test. One of those concepts that we have been test-driving for about a decade was the quota-aware CPU scheduling, which combined CPU-quota trading with priority-based scheduling. However, with Sculpt OS as a major use case of Genode as a desktop OS that focuses on dynamic workloads, it was time to rethink what we expect from a kernel's CPU scheduler.
In this talk, Johannes Schlatow and Stefan Kalkowski share the story and lessons learned from re-designing and re-implementing the kernel scheduler with a particular focus on fairness, tunable latency and ease of configuration.
Redox is a Unix-like microkernel operating system, community developed and written in Rust. Funded through NGI Zero Commons and NLnet, Redox is developing Capability Based Security as a fundamental part of interprocess communication and file I/O. This presentation will look at our strategies for implementing capabilities, POSIX file descriptors, namespaces, containment, and escalation.
As kernels manage hardware, in certain cases the only way to prevent race conditions in kernel code is to disable interrupts. This is a kernel way of granting code exclusive access to resources at lowest levels.
In the realm of embedded devices, it is often not feasible to keep interrupts disabled for prolonged period of time. This affects the design of portions of the kernel which modify data structures accessible from within interrupt context. Despite very limited API offered by the kernel to interrupt handlers, this still affects key data structures in kernel - scheduler table and notification table. This in turn means that any use of threading or notification API would require interrupts to be disabled for potentially prolonged time periods.
To avoid prolonged periods of disabled interrupts we went for some inspiration into the land of lock-free and wait-free programming. We took basic primitives used in lock-free programming and modified them to avoid excessive overhead such primitives have. The resulting mechanism is not lock-free anymore yet offers semantics which allows us to lock (disable interrupts) for much shorter and well predictable periods of time.
The resulting mechanism resembles database transactions to certain extent. This talk will provide introduction to the transaction subsystem, reason on why it offers benefits over raw locks and elaborate on the topic "How not to loose your hair while trying to work with ever-changing data consistently".
This presentation describes the technical implementation of PhantomOS, an orthogonally-persistent operating system, on modern microkernel architecture using the Genode framework. The talk center on the engineering challenges encountered during the porting process, especially the adaptation of the core persistence mechanisms. The talk will also touch on work on network persistence and the added WASM runtime.
As part of the port, the snapshot process was reworked and separated into its own Genode component. The talk will cover how the component utilizes backlink data structures and CRC validation to achieve efficient state storage with minimal overhead. A live demonstration will showcase the reliability and performance characteristics in a real-world environment.
Relevant Links: - PhantomOS: http://phantomos.org - PhantomOS (Genode port): https://github.com/rumenmitov/phantomuserland-snapper - Snapper: https://github.com/rumenmitov/snapper
axle OS (GitHub, blog) is a hobby microkernel and userspace which includes many home-grown utilities such as an x86_64 assembler + ELF linker, a TCP/IP/(ARP/DNS/NIC/etc)]( stack, SATA support, a TrueType renderer, a GameBoy emulator, and more. Everything is built around message passing, from process launches and virtual memory operations, to driver events and GUI updates.
axle OS lacks a GPU driver, but features a compositing desktop window manager with transparency effects and animations. Since the compositor runs on the CPU, I’ve put significant effort into making redraws as efficient and targeted as possible to create a smooth and responsive experience.
In this talk, I’ll give a tour of axle’s CPU-bound compositor from first principles. We’ll go on a journey of live visualisations, seeing how each successive optimization allows the compositor to perform progressively less work per frame, building up towards a general strategy for redraws that comprehensively covers screen updates.
Developing a compositor that plays optimisation tricks involves lots of testing, which can be onerous in an OS that’s primarily developed in an emulator and which must boot itself before the compositor can run. Therefore, we’ll also take a look at a host-side userspace harness I made for the compositor: the compositor can run on my host-native macOS, or as a part of the full axle OS distribution. I developed a simulator which allows me to record user interaction (such as dragging a window around with a mouse), capture the composited frames, and write a test suite that replays these events and ensures the composited frames don’t deviate from the correct output.
We’ll investigate R-trees, different compositing strategies, client request rate limiting, and the various types of redraws that the compositor must be able to handle. This talk aims to be an engaging and ‘interactive’ experience for the audience, with lots of guiding visualisations motivating each optimization we make to our compositor, following the journey towards axle OS’s contemporary CPU compositor.
It has been a while since the last FOSDEM update on GNU/Hurd, so we have a lot to talk about :)
Driver support improvement is on its way through using netbsd's rump layer, now being used in production although there are a few things left to fix. Some SMP support has been added, which should allow at least compilation to be run in parallel. Hurd support was added to the rust ecosystem, which became more and more a necessity due to various software now requiring it. The x86_64 port is essentially complete, which mostly required fixing the MIG RPC layer, and telling various software that it exists. To bootstrap the Debian GNU/Hurd x86_64 distribution, many of the crossbuilding, rebootstrapping and build profiles tools were used to make it relatively smooth. Additionally, the Guix/Hurd distribution is also on its way, as well as an Alpine/Hurd distribution.
Since the first Microkernel OS Devroom at FOSDEM 2012 and culminating today, there have been exactly 15 devrooms in 15 years dedicated to microkernel-based operating systems at each FOSDEM. As surprising or shocking this may sound to somebody who has been there all along, this time period already constitutes a small piece of history. While the computing world of today is not dramatically different or unrecognizable compared to 2012, maybe except for a few "minor" technologies such as HTML5 and LLMs ;), there have definitively been some changes and shifts of priorities.
Let us take this opportunity for a small retrospective of the last 15 years in the context of open-source microkernel-based operating systems. What problems have we been facing back then and how do they relate to the problems we face today? What have been the ups and downs? What are the important lessons learned?