Rust OSDev Operating System Development in Rust

This Month in Rust OSDev: October 2023

Published on (edited by @phil-opp)

Welcome to a new issue of "This Month in Rust OSDev". In these posts, we give a regular overview of notable changes in the Rust operating system development ecosystem.

This series is openly developed on GitHub. Feel free to open pull requests there with content you would like to see in the next issue. If you find some issues on this page, please report them by creating an issue or using our comment form at the bottom of this page.

Announcements, News, and Blog Posts

Here we collect news, blog posts, etc. related to OS development in Rust.

Infrastructure and Tooling

In this section, we collect recent updates to rustc, cargo, and other tooling that are relevant to Rust OS development.

There weren't really any OS-related infrastructure updates this month, but there was some great progress on several upcoming language and tooling features that may also be of interest to OS development:

rust-osdev Projects

In this section, we give an overview of notable changes to the projects hosted under the rust-osdev organization.

spinning_top

Maintained by @phil-opp

The spinning_top crate provides a simple spinlock implementation based on the abstractions of the lock_api crate.

We merged the following changes this month:

Features

Other

Thanks to @mkroening for their contributions!

uefi-rs

Maintained by @GabrielMajeri, @nicholasbishop, and @phip1611

The uefi-rs crate provides safe and performant wrappers for UEFI, the successor to the BIOS. We merged the following PRs this month:

Thanks to @JohnAZoidberg and @JarlEvanson for their contributions!

x86_64

Maintained by @phil-opp, @josephlr, and @Freax13

The x86_64 crate provides various abstractions for x86_64 systems, including wrappers for CPU instructions, access to processor-specific registers, and abstraction types for architecture-specific structures such as page tables and descriptor tables.

We merged the following changes this month:

Thanks to @Wasabi375, @joycebrum, and @mkroening for their contributions!

acpi

Maintained by @IsaacWoods

The acpi repository contains crates for parsing the ACPI tables – data structures that the firmware of modern computers use to relay information about the hardware to the OS. We merged the following changes this month:

Thanks to @alnyan for their contribution!

ovmf-prebuilt

Maintained by @phil-opp and @nicholasbishop

The ovmf-prebuilt project provides pre-built edk2 releases to make it easier to set up OVMF. We merged the following improvement this month:

Thanks to @Firenezz for their contribution!

bootloader

Maintained by @phil-opp

The bootloader crate implements a custom Rust-based bootloader for easy loading of 64-bit ELF executables. This month, we merged the following PRs:

Thanks to @kennystrawnmusic for their contribution!

linked-list-allocator

Maintained by @phil-opp and @jamesmunns

The linked-list-allocator crate provides a basic no_std allocator that builds a linked list from freed memory blocks and thus needs no additional data structures. We merged the following PR this month:

Thanks to @00xc for their contribution!

Other Projects

In this section, we describe updates to Rust OS projects that are not directly related to the rust-osdev organization. Feel free to create a pull request with the updates of your OS project for the next post.

RavnOS

RanvOS, (from norwegian; raven), is a operative system programmed in Rust. Aims to be; minimal, stable, secure and modern ( this maybe you know as; state-of-art ).

The objective of RavnOS is make an operative system minimalist, self hosted (no external crates, all programmed by me), stable and secure.

mkroening/interrupt-mutex

(Section written by @mkroening)

Building upon last month's interrupts crate, I created a mutex for sharing data with interrupt handlers or signal handlers.

RawInterruptMutex wraps any lock_api::RawMutex, be it a parking_lot::RawMutex on Unix or a spinning_top::RawSpinlock on bare metal. When such an InterruptMutex is locked, interrupts are disabled. When the InterruptMutex is unlocked again, the previous interrupt state is restored. This does not completely rule out deadlocks, since you can just enable interrupts manually when you should not. Still, it is very convenient to just change the mutex type of data that is shared with interrupt handlers instead of disabling and enabling interrupts manually on every access.

// Make a mutex of your choice into an `InterruptMutex`.
type InterruptSpinlock<T> = interrupt_mutex::InterruptMutex<spinning_top::RawSpinlock, T>;

static X: InterruptSpinlock<Vec<i32>> = InterruptSpinlock::new(Vec::new());

fn interrupt_handler() {
    X.lock().push(1);
}

let v = X.lock();
// Raise an interrupt
raise_interrupt();
assert_eq!(*v, vec![]);
drop(v);

// The interrupt handler runs

let v = X.lock();
assert_eq!(*v, vec![1]);
drop(v);

mkroening/interrupt-ref-cell

(Section written by @mkroening)

Also building upon last month's interrupts crate, I created a RefCell for sharing data with interrupt handlers or signal handlers on the same thread.

On the same thread (software thread or hardware thread (core)), a compiler fence is sufficient for synchronization with signal handlers (on Unix) and interrupt handlers (on bare metal). In these cases, the new InterruptRefCell allows easy sharing without the overhead of mutexes and without the deadlock potential of mutexes. Similar to InterruptMutex, this is helpful for disabling interrupts on accesses but does not protect you from manually enabling interrupts while holding a reference.

use interrupt_ref_cell::{InterruptRefCell, LocalKeyExt};
 
thread_local! {
    static X: InterruptRefCell<Vec<i32>> = InterruptRefCell::new(Vec::new());
}
 
fn interrupt_handler() {
    X.with_borrow_mut(|v| v.push(1));
}

X.with_borrow(|v| {
    // Raise an interrupt
    raise_interrupt();
    assert_eq!(*v, vec![]);
});
 
// The interrupt handler runs
 
X.with_borrow(|v| assert_eq!(*v, vec![1]));

Join Us?

Are you interested in Rust-based operating system development? Our rust-osdev organization is always open to new members and new projects. Just let us know if you want to join! A good way for getting in touch is our Zulip chat.

Comments