You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Continue working towards Rust for Linux on stable, turning focus from language features to compiler and tooling.
15
14
16
15
## Motivation
17
16
18
-
The [experimental support for Rust development in the Linux kernel][RFL.com] is a watershed moment for Rust, demonstrating to the world that Rust is indeed capable of targeting all manner of low-level systems applications. And yet today that support rests on a [number of unstable features][RFL#2], blocking the effort from ever going beyond experimental status. For 2024H2 we will work to close the largest gaps that block support.
19
-
17
+
This goal continues our push to support the Linux kernel building on stable Rust. The focus in 2025H1 is shifting from language features, which were largely completed in 2024H2, towards compiler flags and tooling support. The Linux Kernel makes use of a number of unstable options in the compiler for target specific optimizations, code hardening, and sanitizer integration. It also requires a custom build of the standard library and has hacky integration with rustdoc to enable the use of doctests. We are looking to put all of these items onto a stable foundation.
@@ -44,84 +43,23 @@ For deeper background, please refer to these materials:
44
43
*[Rust in the linux kernel, by Alice Ryhl](https://www.youtube.com/watch?v=CEznkXjYFb4)
45
44
*[Using Rust in the binder driver, by Alice Ryhl](https://www.youtube.com/watch?v=Kt3hpvMZv8o)
46
45
47
-
### The next six months
48
-
49
-
The RFL project has a [tracking issue][rfl2] listing the unstable features that they rely upon. After discussion with the RFL team, we identified the following subgoals as the ones most urgent to address in 2024. Closing these issues gets us within striking distance of being able to build the RFL codebase on stable Rust.
50
-
51
-
* Stable support for RFL's customized ARC type
52
-
* Labeled goto in inline assembler and extended `offset_of!` support
53
-
* RFL on Rust CI ([done now!])
54
-
* Pointers to statics in constants
55
-
56
-
#### Stable support for RFL's customized ARC type
57
-
58
-
One of Rust's great features is that it doesn't "bake in" the set of pointer types.
59
-
The common types users use every day, such as `Box`, `Rc`, and `Arc`, are all (in principle) library defined.
60
-
But in reality those types enjoy access to some unstable features that let them be used more widely and ergonomically.
61
-
Since few users wish to define their own smart pointer types, this is rarely an issue and there has been relative little pressure to stabilize those mechanisms.
62
-
63
-
The RFL project needs to integrate with the Kernel's existing reference counting types and intrusive linked lists.
64
-
To achieve these goals they've created their own variant of [`Arc`][arclk] (hereafter denoted as `rfl::Arc`),
65
-
but this type cannot be used as idiomatically as the `Arc` type found in `libstd` without two features:
66
-
67
-
* The ability to be used in methods (e.g., `self: rfl::Arc<Self>`), aka "arbitrary self types", specified in [RFC #3519].
68
-
* The ability to be coerce to dyn types like `rfl::Arc<dyn Trait>` and then support invoking methods on `Trait` through dynamic dispatch.
69
-
* This requires the use of two unstable traits, `CoerceUnsized` and `DynDispatch`, neither of which are close to stabilization.
70
-
* However, [RFC #3621] provides for a "shortcut" -- a stable interface using `derive` that expands to those traits, leaving room to evolve the underlying details.
71
-
72
-
Our goal for 2024 is to close those gaps, most likely by implementing and stabilizing [RFC #3519] and [RFC #3621].
Rust sometimes integrates external projects of particular importance or interest into its CI.
90
-
This gives us early notice when changes to the compiler or stdlib impact that project.
91
-
Some of that breakage is accidental, and CI integration ensures we can fix it without the project ever being impacted.
92
-
Otherwise the breakage is intentional, and this gives us an early way to notify the project so they can get ahead of it.
93
-
94
-
Because of the potential to slow velocity and incur extra work,
95
-
the bar for being integrated into CI is high, but we believe that Rust For Linux meets that bar.
96
-
Given that RFL would not be the first such project to be integrated into CI,
97
-
part of pursuing this goal should be establishing clearer policies on when and how we integrate external projects into our CI,
98
-
as we now have enough examples to generalize somewhat.
99
-
100
-
#### Pointers to statics in constants
101
-
102
-
The RFL project has a need to create vtables in read-only memory (unique address not required). The current implementation relies on the `const_mut_refs` and `const_refs_to_static` features ([representative example](https://godbolt.org/z/r58jP6YM4)). Discussion has identified some questions that need to be resolved but no major blockers.
103
-
104
-
### The "shiny future" we are working towards
105
-
106
-
The ultimate goal is to enable smooth and ergonomic interop between Rust and the Linux kernel's idiomatic data structures.
46
+
### What we have done so far
107
47
108
-
In addition to the work listed above, there are a few other obvious items that the Rust For Linux project needs. If we can find owners for these this year, we could even get them done as a "stretch goal":
48
+
We began the push towards stable support for RFL in 2024H2 with [a project goal focused on language features](https://github.com/rust-lang/rust-project-goals/issues/116). Over the course of those six months we:
109
49
110
-
#### Stable sanitizer support
50
+
* Stabilized the `CoercePointee` derive, supporting the kernel's use of smart pointers to model intrusive linked lists.
51
+
* Stabilized basic usage of `asm_goto`. Based on a survey of the kernel's usage, we [modified the existing design](https://github.com/rust-lang/rust/issues/132078) and also proposed [two](https://github.com/rust-lang/rust/issues/128464)[extensions](https://github.com/rust-lang/rust/pull/131523).
52
+
* Stabilized `offset_of` syntax applied to structs.
53
+
* Added Rust-for-Linux to the Rust CI to avoid accidental breakage.
54
+
* Stabilized support for pointers to static in constants.
111
55
112
-
Support for building and using sanitizers, in particular KASAN.
56
+
The one feature which was not stabilized yet is [arbitrary self types v2](https://github.com/rust-lang/rust/issues/44874), which reached "feature complete" status in its implementation. Stabilization is expected in early 2025.
113
57
114
-
#### Custom builds of core/alloc with specialized configuration options
58
+
We also began work on tooling stabilization with an [RFC proposing an approach to stabilizing ABI-modifying compiler flags](https://github.com/rust-lang/rfcs/pull/3716).
115
59
116
-
The RFL project builds the stdlib with a number of configuration options to eliminate undesired aspects of libcore (listed in [RFL#2][]). They need a standard way to build a custom version of core as well as agreement on the options that the kernel will continue using.
117
-
118
-
#### Code-generation features and compiler options
119
-
120
-
The RFL project requires various code-generation options. Some of these are related to custom features of the kernel, such as X18 support ([rust-lang/compiler-team#748]) but others are codegen options like sanitizers and the like. Some subset of the options listed on [RFL#2][] will need to be stabilized to support being built with all required configurations, but working out the precise set will require more effort.
121
-
122
-
#### Ergonomic improvements
60
+
### The next six months
123
61
124
-
Looking further afield, possible future work includes more ergonomic versions of the [special patterns for safe pinned initialization](https://rust-for-linux.com/the-safe-pinned-initialization-problem) or a solution to [custom field projection for pinned types or other smart pointers](https://github.com/rust-lang/rfcs/pull/3318).
62
+
Over the next six months our goal is to stabilize the major bits of tooling used by the Rust for Linux project...
125
63
126
64
## Design axioms
127
65
@@ -134,73 +72,10 @@ Here is a detailed list of the work to be done and who is expected to do it. Thi
134
72
135
73
* The ![Team][] badge indicates a requirement where Team support is needed.
0 commit comments