Kangrejos 2022

The Rust programming language is becoming more and more popular: it's even considered as another language allowed in the Linux kernel.

That brought up the question of architecture support as the official Rust compiler is based on LLVM.

This project, rustc_codegen_gcc, is meant to plug the GCC backend to the Rust compiler frontend as a relatively low-effort: it's a shared library reusing the same API provided by the Rust compiler as the cranelift backend.

As such, it could be used by some Linux projects as a way to provide their Rust softwares to more architectures.

This talk will present this project, its progress and will feature a discussion about what needs to be done to start using it for projects like Rust for Linux.

The Rust-for-Linux project, needing some changes made to the language as well as certain features, depends on a very recent version of Rust. On top of this, due to its complexity and for ergonomic reasons, it makes usage of unstable Rust features - functions, attributes, macros that have not yet been stabilized and are still being worked on by the rustc team.

This does not really pose an issue, as Rust-for-Linux can only be compiled using the official Rust compiler, but proves a challenge for alternative compilers.

In this talk we will give an update on the current status of such an alternative compiler, gccrs, as well as explore the various milestones needed to achieve compilation of the Rust-for-Linux project.

Rust for Linux aims to bring in Rust as a second programming for the Linux Kernel. The Rust for Linux project is making good progress towards being included in upstream Linux sources.

In this talk we discuss status of the Rust NVMe driver. The Rust NVMe driver is interesting as a reference implementation of a high performance driver because NVMe already has a mature and widely deployed driver in the Linux kernel that can be used as a baseline for benchmark purposes.

We discuss Rust language abstractions required to enable the Rust NVMe driver, benchmark results comparing the Rust implementation to the C implementation, and future work.

In this talk we present a 9p file system server for the Linux kernel written using async Rust, then open for discussion. We begin with a brief description of the current state of async Rust in the kernel and the motivation for this project, then we show parts of the server code with the goal of highlighting its simplicity, including the clean up which is done without any additional code (only relying on Drop implementations of existing components). We finish with a demo of mounting a folder from a guest onto the host, before opening up for a discussion on async Rust; topics include additional primitives, reactors, executors and candidates for adoption, what to do with abandoned locks, fault isolation, etc.

In Rust all types are freely moveable. Because of this they cannot depend on having a stable memory location. Some types that are used by the kernel require a stable address, because there exist pointers pointing to them.

In Rust this is achieved via pinning with the pointer wrapper Pin<P>.

Currently initialization of types with self references in the kernel is done via unsafe. This is a great ergonomic hurdle, because one needs two unsafe blocks for the pin-projection and the initialization call.

I present my solution to this problem: a macro that enables initializing structs without having to write unsafe.

It also results in much shorter and easier to read code.

Currently in Rust, types that require pinning are pinned before first use, with no built-in means to initialise a pinned struct directly.

pin-init crate creates a safe abstraction of pinned initialisation using techniques like life branding and typestates with const generics, and use procedural macros to generate the boilerplates to provide an safe, allocation-free, fallible and ergonomical API for initialise structs (recursively) on heap and stack.