Upcoming Rust language features for kernel development
This article brought to you by LWN subscribers Subscribers to LWN.net made this article — and everything that surrounds it — possible. If you appreciate our content, please buy a subscription and make the next set of articles possible.
The Rust for Linux project has been good for Rust, Tyler Mandry, one of the co-leads of Rust's language-design team, said. He gave a talk at Kangrejos 2025 covering upcoming Rust language features and thanking the Rust for Linux developers for helping drive them forward. Afterward, Benno Lossin and Xiangfei Ding went into more detail about their work on the three most important language features for kernel development: field projections, in-place initialization, and arbitrary self types.
Many people have remarked that the development of new language features in Rust can be quite slow, Mandry said. Partly, that can be attributed to the care the Rust language team takes to avoid enshrining bad designs. But the biggest reason is " alignment in attention ". The Rust project is driven by volunteers, which means that if there are not people focusing on pushing a given feature or group of related features forward, they languish. The Rust for Linux project has actually been really helpful for addressing that, Mandry explained, because it is something that a lot of people are excited about, and that focuses effort onto the few specific things that the Linux kernel needs.
Mandry then went through a whirlwind list of upcoming language features, including types without known size information, reference-counting improvements, user-defined function modifiers of the same kind as const , and more. At the end, he asked which of those were most important to Rust for Linux, and how the assembled kernel developers would prioritize them. Beyond the three features to be discussed later, Lossin said that the project definitely wanted the ability to write functions that can be evaluated at compile time (called const functions in Rust) in trait definitions. Danilo Krummrich asked for specialization, which immediately prompted an " Oh no! " from Lossin, due to the feature's nearly decade-long history of causing problems for Rust's type system. Specialization would allow two overlapping implementations for a single trait to exist, with the compiler picking the more specific one. Matthew Maurer asked for some ability to control what the compiler does on integer overflow.
Ultimately, Miguel Ojeda told Mandry that the priority should be on stabilizing the unstable language features that Rust for Linux currently uses, followed by language features that would change how the project structures its code, followed by everything else. The next two talks went into much more detail about the current status and future plans for some of those key language features.
Field projections
Field projection refers to the idea of taking a pointer to a structure, and turning it into a pointer to a field of the structure. Rust does already have this for the built-in reference and pointer types, but it can't always be made to work for user-defined smart-pointer types. Since the Rust for Linux developers would like to have custom smart pointers to handle untrusted data, reference counting, external locking, and related kernel complications, they would benefit from a general language feature allowing field projections for all pointer types using the same syntax. Lossin spoke about his work on the problem, which has been ongoing since Kangrejos 2022. There has been " lots of progress " so far, but the work is still in the design stage, with a few details left to work out.
The built-in field projections all have the same kind of type signature, Lossin explained. For example, the code for converting a reference to an object into a reference to one of its fields and the code for converting a raw pointer to an object into a raw pointer to one of its fields look different, but have similar signatures:
fn project_reference(r: &MyStruct) -> &Field { &r.field } unsafe fn project_pointer(r: *mut MyStruct) -> *mut Field { unsafe { &raw mut (*r).field } } // The equivalent C code would look like this: struct field *project(struct my *r) { return &(r->field); }
... continue reading