Merge pull request #210 from ojeda/rfl

Improvements to the RFL 2025H1 goal

src/2025h1/rfl.md

@@ -14,14 +14,16 @@ Continue working towards Rust for Linux on stable, turning focus from language f
 
 ## Motivation
 
-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.
+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][RFL#2] 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.
 
 [RFL.com]: https://rust-for-linux.com/
 [RFL#2]: https://github.com/Rust-for-Linux/linux/issues/2
 
 ### The status quo
 
-The [Rust For Linux (RFL)][RFL] project has been accepted into the Linux kernel in experimental status. The project's goal, as described in the [Kernel RFC introducing it](https://lore.kernel.org/lkml/[email protected]/), is to add support for authoring kernel components (modules, subsystems) using Rust. Rust would join C as the only two languages permitted in the linux kernel. This is a very exciting milestone for Rust, but it's also a big challenge.
+The [Rust for Linux (RFL)][RFL] project has been accepted into the Linux kernel in experimental status. The project's goal, as described in the [Kernel RFC introducing it][RFL-RFC], is to add support for authoring kernel components (modules, subsystems) using Rust. Rust would join C as the only two languages permitted in the Linux kernel. This is a very exciting milestone for Rust, but it's also a big challenge.
+
+[RFL-RFC]: https://lore.kernel.org/lkml/[email protected]/
 
 Integrating Rust into the Linux kernel means that Rust must be able to interoperate with the kernel's low-level C primitives for things like locking, linked lists, allocation, and so forth.
 This interop requires Rust to expose low-level capabilities that don't currently have stable interfaces.
@@ -30,15 +32,17 @@ This interop requires Rust to expose low-level capabilities that don't currently
 [pinned-init]: https://rust-for-linux.com/pinned-init
 [arclk]: https://rust-for-linux.com/arc-in-the-linux-kernel
 
-The dependency on unstable features is the biggest blocker to Rust exiting "experimental" status. Because unstable features have no kind of reliability guarantee, this in turn means that RFL can only be built with a specific, pinned version of the Rust compiler. This is a challenge for distributions which wish to be able to build a range of kernel sources with the same compiler, rather than having to select a particular toolchain for a particular kernel version.
+The Rust side of the kernel needs to support [a range of compiler versions][RFL-Rust-version-policy], just like the C side does. For instance, distributions wish to be able to build a range of kernel sources with the same compiler, rather than having to select a particular toolchain for a particular kernel version. Thus RFL is already declaring an MSRV. Because unstable features have no kind of reliability guarantee, this in turn means that it is a priority to remove the dependency on unstable features so that Linux can be built with future Rust compilers without major changes on the kernel side.
+
+[RFL-Rust-version-policy]: https://rust-for-linux.com/rust-version-policy
 
 Longer term, having Rust in the Linux kernel is an opportunity to expose more C developers to the benefits of using Rust. But that exposure can go both ways. If Rust is constantly causing pain related to toolchain instability, or if Rust isn't able to interact gracefully with the kernel's data structures, kernel developers may have a bad first impression that causes them to write off Rust altogether. We wish to avoid that outcome. And besides, the Linux kernel is exactly the sort of low-level systems application we want Rust to be great for!
 
 For deeper background, please refer to these materials:
 
-* The article on the latest Maintainer Summit: [Committing to Rust for kernel code](https://lwn.net/Articles/952029/)
+* The article on the latest Maintainers Summit: [Committing to Rust in the kernel](https://lwn.net/Articles/991062/)
 * The [LWN index on articles related to Rust in the kernel](https://lwn.net/Kernel/Index/#Development_tools-Rust)
-* [The latest status update at LPC](https://www.youtube.com/watch?v=qvlgIaYrd3g).
+* [The latest status update at LPC](https://www.youtube.com/watch?v=tamydDnWoLs).
 * [Linus talking about Rust](https://www.youtube.com/watch?v=OvuEYtkOH88&t=335s).
 * [Rust in the linux kernel, by Alice Ryhl](https://www.youtube.com/watch?v=CEznkXjYFb4)
 * [Using Rust in the binder driver, by Alice Ryhl](https://www.youtube.com/watch?v=Kt3hpvMZv8o)
@@ -51,7 +55,7 @@ We began the push towards stable support for RFL in 2024H2 with [a project goal
 * 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).
 * Stabilized `offset_of` syntax applied to structs.
 * Added Rust-for-Linux to the Rust CI to avoid accidental breakage.
-* Stabilized support for pointers to static in constants. 
+* Stabilized support for pointers to static in constants.
 
 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.
 
@@ -69,8 +73,8 @@ Over the next six months our goal is to stabilize the major bits of tooling used
     * production sanitizer flags: `-Zsanitizer=shadow-call-stack`, `-Zsanitizer=kcfi`, `-Zsanitizer-cfi-normalize-integer`.
 * the ability to extract dependency info and to configure no-std without requiring it in the source file:
     * currently using `-Zbinary_dep_depinfo=y` and `-Zcrate-attr`
-* stable rustdoc features allowing the RFL project to extract and customize rustdoc tests:
-* clippy configuration (`.clippy.toml` in particular and `CLIPPY_CONF_DIR`);
+* stable rustdoc features allowing the RFL project to extract and customize rustdoc tests (`--extract-doctests`);
+* clippy configuration (possibly `.clippy.toml` and `CLIPPY_CONF_DIR`);
 * [a blessed way to rebuild std](./build-std.md): RFL needs a way to rebuild the standard library using stable calls to rustc. Currently building the standard library with rustc is not supported. This is a precursor to what is commonly called `-Zbuild-std`; it is also a blocker to making full use of API-modifying compiler flags and similar features, since they can't be used effectively unless the kernel is rebuilt.
 
 In addition, as follow-up from 2024H2, we wish to complete [arbitrary self types v2][astv2] stabilization.