managarm / frigg

Lightweight C++ utilities and algorithms for system programming

The managarm Operating System

What is this about?

This is the main repository of managarm, a microkernel-based operating system.

What is special about managarm? Some notable properties of managarm are: (i) managarm is based on a microkernel while common Desktop operating systems like Linux and Windows use monolithic kernels, (ii) managarm uses a completely asynchronous API for I/O and (iii) despite those internal differences, managarm provides good compatibility with Linux at the user space level.

Aren't microkernels slow? Microkernels do have some performance disadvantages over monolithic kernels. managarm tries to mitigate some of those issues by providing good abstractions (at the driver and system call levels) that allow efficient implementations of common user space functionality (like POSIX).

Is this a Linux distribution? No, managarm runs its own kernel that does not originate from Linux. While the managarm user space API supports many Linux APIs (e.g. epoll, timerfd, signalfd or tmpfs), managarm does not share any source code (or binaries) with the Linux kernel.

Official Discord server: https://discord.gg/7WB6Ur3. This is our primary real-time communication channel.

Official IRC channel: #managarm on irc.libera.chat, with many more available! Type /msg alis list managarm to find them.

Features

• 64-bit operating system with SMP (i.e., multicore) and ACPI support.
• Fully asynchronous microkernel and servers.
• Support for many modern hardware devices such as USB 3 controllers.
• Networking support.
• POSIX and Linux API compatibility.
• Support for Linux-style special files (epoll, signalfd, ...) and pseudo file systems (/sys, /proc, ...).

Trying out managarm

If you want to try out managarm without building the whole OS, you can download a xz-compressed nightly image; these images are automatically compiled on our build server and reflect the current state of Managarm development. To run the (uncompressed) image using qemu, we recommend the following flags:

qemu-system-x86_64 -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 vmware -debugcon stdio

Supported Software

Programs supported on managarm include Weston (the Wayland reference compositor), kmscon (a system console), GNU Coreutils, Bash, nano and others.

Supported Hardware

General USB (UHCI, EHCI)
Graphics Generic VBE graphics, Intel G45, virtio GPU, Bochs VBE interface, VMWare SVGA
Input USB human interface devices, PS/2 keyboard and mouse
Storage USB mass storage devices, NVMe, AHCI, ATA, virtio block

Building managarm

While this repository contains managarm's kernel, its drivers and other core functionality, it is not enough to build a full managarm distribution. Instead, we refer to the Managarm Handbook for build instructions.

frigg's Issues

Unimplemented printf specifier

xinit uses %h during startup in some print statement. I haven't been able to identify which, what or when. The following is logged in E9.

mlibc: Unknown printf terminator '104'

formatting.hpp: Assertion failure

While running nyancat on Managarm, the following assertion failure message is printed continuously:

../../../src/mlibc/subprojects/frigg/include/frg/formatting.hpp:231: Assertion 'padding == ' '' failed!

Relevant code snippet for context:

template<typename P, typename T>
	void print_float(P &formatter, T number, int width = 0, int precision = 6,
			char padding = ' ', bool left_justify = false, bool use_capitals = false,
			bool group_thousands = false, locale_options locale_opts = {}) {
		(void)group_thousands;
		FRG_DEBUG_ASSERT(padding == ' '); // <-- This assert fails

		bool has_sign = false;
		if (number < 0) {
			formatter.append('-');
			has_sign = true;
		}

		bool inf = __builtin_isinf(number), nan = __builtin_isnan(number);
		if (inf || nan) {
			auto total_length = 3 + has_sign;
			auto pad_length = width > total_length ? width - total_length : 0;
			if (!left_justify) {
				while (pad_length > 0) {
					formatter.append(padding);
					pad_length--;
				}
			}

			if (inf)
				formatter.append(use_capitals ? "INF" : "inf");
			else
				formatter.append(use_capitals ? "NAN" : "nan");

			if (left_justify) {
				while (pad_length > 0) {
					formatter.append(padding);
					pad_length--;
				}
			}

			return;
		}

Incorrect cv-qualifier for return type of `array::data() const`

The following program fails to compile:

#include <frg/array.hpp>

class ConstArrayTest 
{
public:
    const int *data() const
    {
        return arr_.data();
    }

private:
    frg::array<int, 5> arr_;
};

ConstArrayTest<int> t;

include/frg/array.hpp:74:30: error: invalid conversion from ‘const value_type*’ {aka ‘const int*’} to ‘int*’ [-fpermissive]
   74 |                 return &_stor[0];
      |                         ~~~~~^
      |                              |
      |                              const value_type* {aka const int*}

This seems to be because in array.hpp the return type of array::data() const is marked constexpr but not const (constexpr makes the pointer type const, but not the pointed-to value).

 constexpr T* data() const noexcept {
//         ^
//         |
//         should be constexpr const T*!
    return &_stor[0];
}

I'm not sure why it works when templated, though.

// compiles no problem

template <typename T>
class ConstArrayTest 
{
public:
    const T *data() const
    {
        return arr_.data();
    }

private:
    frg::array<T, 5> arr_;
};

ConstArrayTest<int> t;

Both examples compile with the GNU implementation of the C++ Standard Library, which does declare the return type const:

_GLIBCXX17_CONSTEXPR const_pointer
data() const noexcept
{ return _AT_Type::_S_ptr(_M_elems); }

expected: map([...] (...) -> expected<...> { ... }) produces expected<expected>

While this behavior is probably fine, it would be desirable to be able to chain expecteds for monadic operations.

For an example of such see Haskell's Either

-- Module      :  Data.Either
-- Copyright   :  (c) The University of Glasgow 2001
-- License     :  BSD-style (see the file libraries/base/LICENSE)

-- | @since 4.4.0.0
instance Monad (Either e) where
    Left  l >>= _ = Left l
    Right r >>= k = k r

In essence, this means that >>= propagates error and does not evaluate k (type: a -> Either e b) unless the Either is a Right (success case)

EDIT: similarly, there's no way to implicitly convert to a different expected result of same error (one would have to do if (!e) { {co_}return e.error(); })

Frigg assertion failure during printing

While testing out the fixes for #14, I ran into the following problem

../../../src/mlibc/subprojects/frigg/include/frg/printf.hpp:57: Assertion 'opts->arg_pos <= vsp->num_args' failed!

Tested with the --help commands of:

• mount,
• fdisk,
• choom,
• findmnt,
• flock,
• getopt,
• mountpoint,
• renice,
• umount,
• agetty,
• cfdisk,
• losetup,
• sfdisk,
• zramctl.

formatting.hpp: szmod assert fails

(In formatting.hpp, do_printf_chars)
case 'c': FRG_ASSERT(!opts.fill_zeros); FRG_ASSERT(!opts.left_justify); FRG_ASSERT(!opts.alt_conversion); ---->FRG_ASSERT(szmod == printf_size_mod::default_size); Fails when running Python 3.8

Unimplemented printf specifier

The following applications from util-linux use $ while printing their help message.

• mount,
• fdisk,
• choom,
• findmnt,
• flock,
• getopt,
• mountpoint,
• renice,
• umount,
• agetty,
• cfdisk,
• losetup,
• sfdisk,
• zramctl.

The following is logged in E9 for all of them.

mlibc: Unknown printf terminator '36'

Report the error and location in frg::expected::unwrap

Currently, if unwrap fails, it simply triggers an assertion failure, which provides no indication as to what happened.

Make gtest dependency optional or add a wrap

Currently, this makes downstream CI fail: https://github.com/managarm/managarm/runs/6953595720

Deduplicate parts of code between basic_string and basic_string_view

Certain basic_string operations (such as comparisons) can be implemented in terms of basic_string_view: e.g.:

bool operator==(const basic_string &other) const {
    return basic_string_view<Char>{_buffer, _length} == basic_string_view<Char>{other._buffer, other._length};
}

We could also add a convenience basic_string::view() method that does the view construction.

Doing this will allow us to more easily prevent bugs like the one fixed by 264af2d.

Missing support for certain floating point printf specifiers

%g, %G, %e, %E are unimplemented, which breaks Xash3D.

Import priority queue from managarm repository

The old frigg had a nice priority queue based on binary heaps (source code). Import it into this repository.