Conveners
Rust MC
- Miguel Ojeda
Description
Rust is a systems programming language that is making great strides in becoming the next big one in the domain. Rust for Linux is the project adding support for the Rust language to the Linux kernel.
Rust has a key property that makes it very interesting as the second language in the kernel: it guarantees no undefined behavior takes place (as long as unsafe code is sound). This includes no use-after-free mistakes, no double frees, no data races, etc. It also provides other important benefits, such as improved error handling, stricter typing, sum types, pattern matching, privacy, closures, generics, etc.
This microconference intends to cover talks and discussions on both Rust for Linux as well as other non-kernel Rust topics.
Possible Rust for Linux topics:
- Rust in the kernel: status updates and discussion on next steps.
- Use cases for Rust around the kernel: subsystems, drivers, other modules...
- Developing-related discussions: how to abstract existing subsystems safely and API design, coding guidelines, safety guidelines...
- Upstreaming process: guidance on how to get into mainline, strategies that have worked for Rust code in the past, getting involved...
- Maintanance: the new subentries and branches, the proposed cross-subsystem subteams (e.g. the safety team), scaling work for the future, any cross-subsystem issues...
- Infrastructure: build system, documentation, testing and CIs, maintenance, unstable features, architecture support, stable/LTS releases, Rust versioning, third-party crates...
- klint.
- pin-init.
- The future of GCC builds.
Possible Rust topics:
- Language and standard library: discussion on upcoming features, stabilization of the remaining features the kernel needs, memory model, the 2024 edition...
- Compilers and codegen:
rustcimprovements, LLVM and Rust,rustc_codegen_gcc,gccrs... - Other tooling and new ideas: Coccinelle for Rust,
bindgen, Compiler Explorer, Cargo, Clippy, Miri... - Educational material.
- Any other Rust topic within the Linux ecosystem.
Last year was the third edition of the Rust MC and the focus was on discussing the ongoing efforts by different parties that are upstreaming new Rust abstractions and drivers (Giving Rust a chance for in-kernel codecs, hrtimer Rust Abstractions, Atomics and memory model for Rust code in kernel). We also had a topic related to improving the ergonomics and tooling around Rust in the kernel (Coccinelle for Rust) and a tutorial session to help others learn Rust (Introduction to Rust: Quality of Life Beyond Memory Safety), as well as a "Birds of a Feather" slot for open discussion on other topics.
Since the MC last year, it is easy to notice how Rust work around the kernel is accelerating: patches and contributors keep growing, new MAINTAINERS entries have been created and new maintainers have stepped up, new use cases have been developed and/or merged (e.g. the AMCC QT2025 PHY driver and Android ashmem), new projects have been announced (e.g. Tyr)... Even some end users of Linux distributions have already interacted with Rust kernel code in the wild (via the QR code panic screen). This all signifies success, but also poses new challenges ahead.
Note that this year submissions for the Rust MC should aim to be more discussion oriented.
Suggested attendees: the Rust for Linux team (Miguel Ojeda, Boqun Feng, Gary Guo, Benno Lossin, Andreas Hindborg, Alice Ryhl, Trevor Gross, Danilo Krummrich), Abdiel Janulgue, Alexandre Courbot, Alistair Francis, Arnaldo Carvalho de Melo, Bjorn Helgaas, Burak Emir, Christian Brauner, Christian Schrefl, Daniel Almeida, Dave Airlie, David Gow, Dirk Behme, Fiona Behrens, Frederic Weisbecker, FUJITA Tomonori, Greg Kroah-Hartman, Igor Korotin, Ingo Molnar, Jocelyn Falempe, Joel Fernandes, Kees Cook, Liam R. Howlett, Lorenzo Stoakes, Luis Chamberlain, Lyude Paul, Masahiro Yamada, Matthew Maurer, Nathan Chancellor, Paolo Bonzini, Paul E. McKenney, Peter Zijlstra, Remo Senekowitsch, Rob Herring, Robin Murphy, Sami Tolvanen, Stephen Boyd, Tamir Duberstein, Tejun Heo, Thomas Gleixner, Viresh Kumar, Will Deacon, Yury Norov...
-
Alexandre Courbot (NVIDIA)12/12/2025, 10:00
One of the main selling points for Rust's inclusion in the kernel is safety, which is strongly associated with a reduction of runtime panics. Yet, in Rust an integer overflow or out-of-bounds array access translates into an implicit panic, inserted without any warning to the programmer.
The inability to easily identify where these implicit panic sites are introduced creates a blind spot...
Go to contribution page -
Mr Andreas Hindborg (Samsung)12/12/2025, 10:20
Some C kernel data structures exposed to Rust code apply internal
synchronization (XArray). Depending on the type of lock, such data structures
need to unlock locks when allocating memory. Sometimes it is beneficial to use a
single external lock to protect multiple such data structures.In Rust this creates a problem that is not present in C. This is because that
Go to contribution page
mutably borrowing... -
Benno Lossin12/12/2025, 10:40
Rust in the Linux kernel uses the
pin-initlibrary for initialization. This library handles ergonomic and safe initialization of address-sensitive types such asMutex<T>(the abstraction ofstruct mutex).Since address sensitivity is an inherited property (a type containing an address-sensitive type also becomes one), lots of types require using the
Go to contribution pagepin-initAPI to initialize them.... -
Xiangfei Ding12/12/2025, 12:00
This activity comprises of two parts. First it will be a short update on the development of language features as we close the chapter on the Rust project goal 2025H2, covering features like arbitrary_self_types and trait evolution and the projected availability of the features on stable Rust releases and focusing on how this enables better kernel developer experience when working on Linux...
Go to contribution page -
Rahul Rameshbabu12/12/2025, 12:20
As HID support in Rust is being developed, a number of challenges are arising during the development process. Binding the C API that represents different HID structures will grow verbose as more HID logic is supported in Rust. Specialized HID device drivers will want to make use of APIs from other subsystems, such as input and DRM. Otherwise, such drivers tend to be isolated to HID report...
Go to contribution page -
Vitaly Wool12/12/2025, 12:40
RCU (Read-Copy-Update) is a great mechanism in the Linux kernel for read-mostly situations. However, it is used almost exclusively on the C side and there's virtually no support for it on the Rust side. While there are plans to implement RCU in Rust using projections, those are largely still in the making, and the author believes there are some special cases worth addressing now, for instance,...
Go to contribution page -
Jinghao Jia (University of Illinois Urbana-Champaign), Ruowen Qin12/12/2025, 13:00
TL;DR We propose to present the Rex project (Rust-based kernel extension) and discuss its integration with Rust for Linux.
Rex is a Rust-based kernel extension framework (https://github.com/rex-rs/rex). It offers similar safety guarantees as eBPF. Different from eBPF, which verifies the safety of extension code via an in-kernel verifier, Rex builds its safety guarantees atop the...
Go to contribution page -
Mrs Alice Ryhl (Google), Daniel Almeida (Collabora)
Showcase the current state of Tyr, a new Rust kernel driver for Arm Mali GPUs, briefly mentioning current status of the driver and the associated Rust abstractions needed to support it, as well as the future plans for both upstream and Android.
The discussion should be centered on whether the current upstreaming plan makes sense to the DRM community, considering our efforts both upstream...
Go to contribution page -
Mrs Alice Ryhl (Google), Daniel Almeida (Collabora)
Showcase the current state of Tyr, a new Rust kernel driver for Arm Mali GPUs, briefly mentioning current status of the driver and the associated Rust abstractions needed to support it, as well as the future plans for both upstream and Android.
The discussion should be centered on whether the current upstreaming plan makes sense to the DRM community, considering our efforts both upstream...
Go to contribution page
