This Month in Rust OSDev (January 2021)
Welcome to a new issue of "This Month in Rust OSDev". In these posts, we will 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.
We started a new Showcase section this month, where we introduce and present interesting Rust OSDev projects. The first post of this section is:
If you like to present your project too, just let us know!
In this section, we give an overview of notable changes to the projects hosted under the
bootloader crate implements a custom Rust-based bootloader for easy loading of 64-bit ELF executables. While we didn't merge any commits to our
main branch this month, we made good process on the UEFI rewrite:
- Update uefi crate to v0.7.0
- Add bootloader version to boot info
- Make boot info FFI-safe
- Start providing API docs for all public items
- Add a test that checks boot info values
- Create FAT file system image from
- Create a GPT disk image with an UEFI boot partition
- Only copy first level 4 entry to bootloader page table
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. In Januar, we added some updates to the
uart_16550 crate provides basic support for serial port I/O for 16550-compatible UARTs. The crate received the following maintenance update in January:
cargo-xbuild project provides
cargo command wrappers to cross-compile the sysroot crates
alloc. This month, we fixed an error that occurred in combination with the
XARGO_RUST_SRC environment variable:
- Ensure copied Cargo.lock is writable (published as
Thanks to @astro for this contribution!
Even though we still maintain the
cargo-xbuild crate, we recommend switching to cargo's own
build-std feature that is always up-to-date with the latest Rust/Cargo changes. We wrote a short guide on how to switch to it, which is available in our Readme.
RustyHermit is a unikernel targeting a scalable and predictable runtime for high-performance and cloud computing. This month, we revise the paravirtualized network driver (virtio) and add a simple driver for RTL8139, which Qemu is able to emulate. With the support of KubeVirt, Kubernetes is able to orchestrate RustyHermit applications. As simple show case is explained in RustyHermit's wiki.
In this section, we describe updates to personal 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.
(Section written by @phil-opp)
We made good progress on the Persian and Japanese translations of the "Writing an OS in Rust" blog this month:
- Make index page translatable
- Improve multilingual support and Persian translation
- Persian translation of chapter Interrupts
- Fix layout of right-to-left in homepage and tables
- Adding tracking issue for Persian
- Translate post-04 to Japanese
- Translate common texts into Japanese
- Translate the index page to Japanese
In addition to the new translations, we merged the following improvements:
- Improve explanation for
- Added note to specify version 0.2.6 of volatile
- Remove unused import
- Fix typo
- Remove trailing comma in JSON example
- Fix memory address in self-referential struct example
As I already mentioned in the previous posts, I'm working on a new 3rd edition of the blog. The new edition will be compatible with UEFI, use a pixel-based framebuffer, and utilize the APIC instead of the legacy PIC for interrupt handling.
As mentioned above, we added support for UEFI disk image creation to the new
bootloader version this month. This made it finally possible to start the rewritten
blog_os code in UEFI mode on real hardware:
This is an old Acer TravelMate laptop of mine, booting from a USB stick. The output shows that it successfully sets up the local and IO-APIC for interrupt handling and then listens for timer and keyboard interrupts, just as before. The screen output is now based on a pixel-based framebuffer, using the
font8x8 crate for simple font rendering. The memory management code required almost no changes, since the interface provided by the bootloader stayed almost the same (there are only some differences in the memory map format).
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 gitter channel.