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...
- Maintenance: 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.
Please remember that submissions for microconferences (like the Rust MC) should be discussion oriented. Please see "The Ideal Microconference Topic Session".
Last year was the 4th edition of the Rust MC. We had technical discussions around Rust abstractions for the kernel (Overflowing with Fear: Detecting and Mitigating Implicit Panics in Rust, External locking for internally synchronized data structures, Tackling challenges with HID and related device driver support in Rust, Exploring a real life RCU use case for Rust), as well as a presentation and discussion around Rust language features needed by the kernel (Rust language evolutions for better kernel developer experience) and about a Rust-based kernel extension framework (Rex and its integration with Rust-for-Linux). In addition, we had a tutorial session again (Initialization in Rust with pin-init). Finally, we also had a "Birds of a Feather" slot (Rust for Linux Office Hours) for open discussion on other topics.
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, Alexei Starovoitov, 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, Julia Lawall, Kees Cook, Liam R. Howlett, Lorenzo Stoakes, Luis Chamberlain, Lyude Paul, Masahiro Yamada, Matthew Maurer, Nathan Chancellor, Onur รzkan, Paolo Bonzini, Paul E. McKenney, Peter Zijlstra, Remo Senekowitsch, Rob Herring, Robin Murphy, Sami Tolvanen, Stephen Boyd, Tamir Duberstein, Tathagata Roy, Tejun Heo, Thomas Gleixner, Viresh Kumar, Will Deacon, Yury Norov...
-
Dr Gary Guo (Red Hat)07/10/2026, 10:00
Self-reference is a common need in kernel code. In fact, this is what motivates the development of
Go to contribution pagepin-init. So far, self-references can only be created with unsafe code with explicit use ofOpaque. This is a discussion about on-going working to support safe creation of self references in thepin-initcrate. -
Mr Andreas Hindborg (Samsung)07/10/2026, 10:20
The
kernel::block::mq::Requesttype [1] sits on the I/O hot path of every Rust block device driver. ARequestis jointly referenced by the block layer and the driver, with completion arriving on multiple asynchronous paths, so the type has to encode a non-trivial sharing and lifecycle model with minimal runtime cost.The introduction of
Go to contribution pageOwnable[2] gave us a general mechanism for... -
Philipp Stanner07/10/2026, 10:40
The kernel's dma_fence subsystem lays at the heart of every graphics processing unit (GPU) driver. It is a primitive for synchronizing the state of jobs running on GPUs with receiver parties, notably userspace. A number of circumstances make the correct implementation and usage of both C and Rust dma_fence very challenging:
- The highly asynchronous nature of GPUs, including the fact that...
-
Daniel Almeida (Collabora)07/10/2026, 11:00
Briefly cover the status of the Tyr project and discuss the current blockers in upstream, specially those related to missing Rust abstractions. This presentation intends to discuss and validate the job submission model, including the proposed GPUVM/JobQueue Rust abstractions and their current upstream status, showcasing the different designs between Tyr's initial implementation and what is...
Go to contribution page -
Michaล Wilczyลski07/10/2026, 12:00
Problem Statement:
Independent developers driving new Rust bindings often face a major bottleneck: getting their work mainlined by hesitant C subsystem maintainers, and just as importantly, sustaining that collaboration post-merge. Translating modern Rust architectures to maintainers who evaluate designs strictly through C paradigms remains a massive hurdle.Session Focus:
Go to contribution page
The PWM... -
Alice Ryhl (Google)07/10/2026, 12:20
Rust is expanding into more and more places, and it's becoming clear that Rust creates some unique challenges when it comes to drivers that are out-of-tree.
Like all other Rust drivers, out-of-tree drivers written in Rust require abstractions for the subsystems they interact with. If the driver requires a subsystem that does not yet have abstractions, or if the abstractions exist but are...
Go to contribution page -
Michal Rostecki (Anza)07/10/2026, 12:40
Writing BPF programs in the long past meant wrestling with Linux kernel version fragmentation. That problem was solved, many years ago, thanks to CO-RE (Compile Once, Run Everywhere) relocations. CO-RE is a mechanism that uses the BTF type format and its relocation entries (
Go to contribution pageBTF.ext) to handle layout differences, by patching the loaded BPF bytecode with correct offsets that match the running...