managarm: an asynchronous microkernel OS with Linux-compatible user space

Why managarm separates the kernel from POSIX compatibility

managarm addresses a specific operating-system design problem: implementing a microkernel and asynchronous I/O without discarding familiar application interfaces. The repository describes it as a microkernel-based system, unlike the monolithic Linux and Windows kernels cited by its documentation. It also states that its I/O API is completely asynchronous, both in the kernel and in servers.

The user-space side supports a substantial set of Linux and POSIX conventions. The README specifically names epoll, timerfd, signalfd, tmpfs, /sys, and /proc. Linux-style special files and pseudo file systems let existing userspace mechanisms interact with resources through familiar paths and file descriptors. This does not make managarm a Linux distribution. Its documentation is explicit that managarm has its own kernel, does not originate from Linux, and shares neither source code nor binaries with the Linux kernel.

That boundary matters for evaluation. managarm is aimed partly at developers who want asynchronous, microkernel-oriented system architecture while retaining enough API compatibility to run familiar software. Supported examples include Weston, kmscon, KDE Plasma 6, GNU Coreutils, Bash, and nano. Those names establish a working direction, but the README does not claim unrestricted binary compatibility with Linux software.

The kernel, servers, drivers, and protocol layout

Based on the repository layout, this main repository contains more than the kernel. Its top-level entries include kernel/, drivers/, servers/, posix/, protocols/, mbus/, hel/, and sif/. There are also Rust components and a Cargo workspace, testsuites/, documentation, CI configuration, utilities, and supporting tools.

This separation matches the microkernel model. The kernel is the core operating-system component, while drivers and servers provide system functions outside that kernel. The repository includes protocol definitions in protocols/, which indicates an interface boundary through which separately built components can communicate. The mbus directory also appears, based on its name and placement, to be associated with the system's message-oriented component structure, although the README does not document its internal protocol in enough detail to describe packet flow or synchronization.

The Rust side is not a separate consumer application. Cargo.toml defines a workspace containing sif, posix/devserver, servers/kernletcc, drivers/dmalog, and utils/hello-rs. Shared dependencies include the local hel, hel-sys, managarm, and managarm-arch crates, plus uacpi-sys, zerocopy, and workspace coordination through resolver = "3". The repository therefore combines C++ core areas with Rust utilities and services.

The documentation does not provide a kernel boot trace, scheduler algorithm, IPC benchmark, or detailed device-to-user-space request sequence. Claims beyond the broad mechanism should therefore be treated as open questions rather than inferred from directory names.

Trying managarm through the nightly x86-64 image

The fastest first use documented by the project is a nightly image rather than a local build. The README points to an xz-compressed image produced by the build server. Download and decompress that image before using the documented QEMU command. The download and decompression commands are not provided in the README, so the page does not invent them.

The following command starts the uncompressed image with QEMU. It enables KVM, allocates 2048 MB of memory, exposes a USB keyboard and tablet, attaches the image through virtio-blk, and directs the debug console to standard I/O:

qemu-system-x86_64 -display gtk,zoom-to-fit=off -enable-kvm -m 2048 -cpu host,migratable=off -device qemu-xhci -device usb-kbd -device usb-tablet -drive id=hdd,file=image,format=raw,if=none -device virtio-blk-pci,drive=hdd -vga virtio -debugcon stdio

Use the credentials documented by the project:

user: managarm
password: managarm

The first block requires QEMU with the relevant machine support, KVM availability on the host, and a file named image after decompression. The README recommends the GTK display and the exact device configuration shown, but it does not document a headless alternative. This tutorial therefore cannot claim that it works on every host or in every environment.

The nightly image reflects current development rather than a stable release. The repository has no GitHub releases, so there is no release artifact or tagged stable image identified in the available documentation.

Why the repository alone cannot produce a complete distribution

A local build is a different task from trying the nightly image. The README warns that the repository contains managarm's kernel, drivers, and other core functionality, but is not sufficient to build a full managarm distribution. It directs developers to the Managarm Handbook's building instructions.

The top-level Meson files indicate that at least part of the system participates in a Meson-based build. However, the README does not state that running meson setup or ninja from the repository root will produce a bootable image. No exact toolchain versions, bootstrap command, image target, or complete dependency list appears in the README.

The Cargo workspace is narrower as well. Its members cover a specific set of Rust components, not a complete distribution image. The correct local-build procedure therefore needs to come from the linked handbook rather than inference from Cargo.toml. This distinction prevents a common evaluation mistake: cloning the repository does not make it a self-contained installer or a turnkey Linux replacement.

The absence of GitHub releases also means upgrade behavior is undocumented. There is no stated release channel, migration procedure, compatibility matrix, or rollback policy in the README. The last repository push was on 2026-10-14, but that fact alone does not establish a stable release cadence.

Hardware and software coverage require explicit checking

managarm's compatibility claims are concrete but selective. For storage, the documented devices include USB mass storage, NVMe, AHCI, ATA, and virtio block. Graphics support covers generic VBE, Intel G45, virtio GPU, Bochs VBE, VMware SVGA, and Nvidia Turing or later. Input includes USB HID devices as well as PS/2 keyboard and mouse devices.

Networking includes USB CDC ECM/NCM Ethernet devices, USB MBIM cellular modems, RTL8168 devices, and Intel Gigabit Ethernet devices. USB controller coverage lists UHCI, EHCI, and XHCI. Serial support includes UART, CP2102, and FTDI FT232 adapters.

This is enough to define the intended evaluation target, but not enough to infer broad device compatibility. For example, the README does not claim support for every Wi-Fi chipset, every GPU generation, or every NVMe controller. It also does not explain partial device behavior, firmware requirements, or recovery after driver failure.

On the software side, the README names KDE Plasma 6, Weston, kmscon, Bash, GNU Coreutils, and nano. This suggests a desktop-oriented userspace path, but it does not publish version matrices for those components or a list of known failures. The asynchronous API and Linux-style facilities are valuable architectural features, yet application compatibility must be verified individually rather than inferred from the broad phrase "POSIX and Linux API compatibility."

Maintenance, licensing, and upgrade implications

The repository is not archived, and its last push was on 2026-10-14. That is recent activity, but the available documentation does not define an active-development promise, support window, release cadence, or patch policy. With no GitHub releases, there is no documented stable version to pin in the repository information.

The project uses the MIT license. That is a permissive license with broad permission to use, copy, modify, merge, publish, distribute, sublicense, and sell copies, subject to its conditions and disclaimer. Projects integrating or redistributing managarm code should retain the required license notice and review the actual LICENSE file and dependency licenses. This is a technical notice about the repository's stated licensing model, not legal advice.

Upgrading may also involve more than replacing one prebuilt disk image. The repository combines kernel, drivers, servers, protocols, POSIX components, Rust crates, tests, and tools. The README does not document whether a full userspace must be rebuilt when protocol or kernel interfaces change. That missing compatibility policy matters most to developers planning long-lived forks rather than users running a nightly image for evaluation.

Editorial conclusion

managarm fits developers and researchers who want to inspect or experiment with a fully asynchronous microkernel and accept a selective hardware and software matrix. It is a poor choice for production deployment or for users who require broad Linux application compatibility. Before adoption, verify the exact application and device needs against the documented supported-software and supported-hardware lists, then use the published QEMU image as the first acceptance test.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. managarm/managarm on GitHub
4. README