Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix a few links #214

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 4 additions & 2 deletions src/2025h1/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -46,7 +46,7 @@ The flagship goals proposed for this roadmap are as follows:
* improve the ergonomics of `Pin`, which is frequently used in low-level async code; and
* prepare to support asynchronous (and synchronous) generators in the language.
* Continue helping Rust support low-level projects by [**stabilizing compiler options and tooling used by the Rust-for-Linux (RFL) project**](./rfl.md). In 2025H1 we plan to:
* implement RFC #3716 to allow stabilizing ABI-modifying compiler flags to control code generation, sanitizer integration, and so forth;
* implement [RFC 3716] to allow stabilizing ABI-modifying compiler flags to control code generation, sanitizer integration, and so forth;
* taking the first step towards stabilizing [`build-std`](https://doc.rust-lang.org/cargo/reference/unstable.html#build-std) by [creating a stable way to rebuild core with specific compiler options](./build-std.md);
* add rustdoc features to extract and customize rustdoc tests (`--extract-doctests`);
* stabilize clippy configuration like `.clippy.toml` and `CLIPPY_CONF_DIR`;
Expand All @@ -55,11 +55,13 @@ The flagship goals proposed for this roadmap are as follows:
* convene Rust maintainers to celebrate Rust's tenth birthday at [RustWeek 2025](https://2025.rustweek.org) (co-organized with [RustNL](https://2025.rustweek.org/about/);
* author a first draft for a [Rust vision doc](./rust-vision-doc.md) and gather feedback.

[RFC 3716]: https://github.com/rust-lang/rfcs/pull/3716
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm. There is a linkifier declared:

[preprocessor.goals.linkifiers]
"RFC #([0-9]+)" = "https://github.com/rust-lang/rfcs/pull/$1"
"([a-zA-Z0-9-]+)/([a-zA-Z0-9-]+)#([0-9]+)" = "https://github.com/$1/$2/issues/$3"
"#([0-9]+)" = "https://github.com/rust-lang/rust/issues/$1"

I don't get why it's not working...?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

#204 was the bug I was thinking of

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Doesn't that only parse RFC #3716, not RFC 3716?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I assume it should be RFC #?([0-9]+) if we want to allow both.


#### Why these particular flagship goals?

[**Async.**](./async.md) Rust is a great fit for server development thanks to its ability to scale to very high load while retaining low memory usage and tight tail latency. 52% of the respondents in the [2023 Rust survey](https://blog.rust-lang.org/2024/02/19/2023-Rust-Annual-Survey-2023-results.html) indicated that they use Rust to build server-side or backend applications. In [2025H1 our plan](./async.md) is to deliver (a) improved support for async-fn-in-traits, completely subsuming the functionality of the [`async-trait` crate](https://crates.io/crates/async-trait); (b) finalize a design for sync and async generators, simplifying the creation of iterators and async data streams; (c) and improve the ergonomics of `Pin`, making lower-level async coding more approachable. These items together start to unblock the creation of the next generation of async libraries in the wider ecosystem, as progress there has been blocked on a stable solution for async traits and streams.

[**Rust for Linux.**](./rfl.md) The [experimental support for Rust development in the Linux kernel][https://rust-for-linux.com/] is a watershed moment for Rust, demonstrating to the world that Rust is indeed a true alternative to C. Currently the Linux kernel support depends on a wide variety of unstable features in Rust; these same features block other embedded and low-level systems applications. We are working to stabilize all of these features so that RFL can be built on a stable toolchain. As we have successfully stabilized the majority of the language features used by RFL, we plan in 2025H1 to turn our focus to compiler flags and tooling options. We will (a) implement RFC #3716 which lays out a design for ABI-modifying flags; (b) take the first step towards stabilizing [`build-std`](https://doc.rust-lang.org/cargo/reference/unstable.html#build-std) by [creating a stable way to rebuild core with specific compiler options](./build-std.md); (c) extending rustdoc, clippy, and the compiler with features that extract metadata for integration into other build systems (in this case, the kernel's build system).
[**Rust for Linux.**](./rfl.md) 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 a true alternative to C. Currently the Linux kernel support depends on a wide variety of unstable features in Rust; these same features block other embedded and low-level systems applications. We are working to stabilize all of these features so that RFL can be built on a stable toolchain. As we have successfully stabilized the majority of the language features used by RFL, we plan in 2025H1 to turn our focus to compiler flags and tooling options. We will (a) implement [RFC 3716] which lays out a design for ABI-modifying flags; (b) take the first step towards stabilizing [`build-std`](https://doc.rust-lang.org/cargo/reference/unstable.html#build-std) by [creating a stable way to rebuild core with specific compiler options](./build-std.md); (c) extending rustdoc, clippy, and the compiler with features that extract metadata for integration into other build systems (in this case, the kernel's build system).

[**Rust All Hands 2025.**](./all-hands.md) May 15, 2025 marks the 10-year anniversary of Rust's 1.0 release; it also marks 10 years since the [creation of the Rust subteams](https://internals.rust-lang.org/t/announcing-the-subteams/2042). At the time [there were 6 Rust teams with 24 people in total](http://web.archive.org/web/20150517235608/http://www.rust-lang.org/team.html). There are now 57 teams with 166 people. In-person All Hands meetings are an effective way to help these maintainers get to know one another with high-bandwidth discussions. This year, the Rust project will be coming together for [RustWeek 2025](https://2025.rustweek.org), a joint event organized with [RustNL](https://2025.rustweek.org/about/). Participating project teams will use the time to share knowledge, make plans, or just get to know one another better. One particular goal for the All Hands is reviewing a draft of the [Rust Vision Doc](./rust-vision-doc.md), a document that aims to take stock of where Rust is and lay out high-level goals for the next few years.

Expand Down
14 changes: 8 additions & 6 deletions src/2025h1/rfl.md
Original file line number Diff line number Diff line change
Expand Up @@ -16,7 +16,6 @@ Continue working towards Rust for Linux on stable, turning focus to compiler and

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
Expand Down Expand Up @@ -57,15 +56,15 @@ We began the push towards stable support for RFL in 2024H2 with [a project goal
* Added Rust-for-Linux to the Rust CI to avoid accidental breakage.
* 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.
The one feature which was not stabilized yet is [arbitrary self types v2][astv2], which reached "feature complete" status in its implementation. Stabilization is expected in early 2025.

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).

### The next six months

Over the next six months our goal is to stabilize the major bits of tooling used by the Rust for Linux project. Some of these work items are complex enough to be tracked independently as their own project goals, in which case they are linked.

* implementing RFC #3716 to allow stabilizing ABI-modifying compiler flags to control code generation, sanitizer integration, and so forth
* implementing [RFC 3716] to allow stabilizing ABI-modifying compiler flags to control code generation, sanitizer integration, and so forth
* 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 (`--extract-doctests`);
Expand All @@ -74,6 +73,9 @@ Over the next six months our goal is to stabilize the major bits of tooling used

In addition, as follow-up from 2024H2, we wish to complete [arbitrary self types v2][astv2] stabilization.

[RFC 3716]: https://github.com/rust-lang/rfcs/pull/3716
[astv2]: https://github.com/rust-lang/rust/issues/44874

### The "shiny future" we are working towards

The ultimate target for this line of work is that Rust code in the Linux kernel builds on stable Rust with a Minimum Supported Rust Version (MSRV) tied to some external benchmark, such as Debian stable. This is the minimum requirement for Rust integration to proceed from an "experiment" so something that could become a permanent part of Linux.
Expand Down Expand Up @@ -103,7 +105,7 @@ Goal: stabilizing various ABI-modifying flags such as `-Zbranch-protection` and
| Task | Owner(s) or team(s) | Notes |
|------------------------|------------------------|---------------------------------------------------------|
| Author RFC | @darksonn | ![Completed][] |
| RFC decision | ![Team][] [compiler][] | RFC #3716, currently in PFCP |
| RFC decision | ![Team][] [compiler][] | [RFC 3716], currently in PFCP |
| Implementation | ![Help Wanted][] | For each flag, need to move flags from `-Z` to `-C` etc |
| Standard reviews | ![Team][] [compiler] | |
| Stabilization decision | ![Team][] [compiler][] | For each of the relevant compiler flags |
Expand Down Expand Up @@ -152,12 +154,12 @@ See [build-std](./build-std.md) goal.

### What kind of compiler flags will Rust-for-Linux need?

Implementing RFC #3716, coupled with a [blessed way to build std](./build-std.md), will allow the full use of flags that modify the ABI. We will need to ultimately stabilize the full set of flags used by RFL, which include at least the following:
Implementing [RFC 3716], coupled with a [blessed way to build std](./build-std.md), will allow the full use of flags that modify the ABI. We will need to ultimately stabilize the full set of flags used by RFL, which include at least the following:

* arm64: `-Zbranch-protection`, `-Zfixed-x18`, `-Zuse-sync-unwind`.
* x86: `-Zcf-protection`, `-Zfunction-return`, `-Zno-jump-tables`, `-Zpatchable-function-entry`, retpoline (`+retpoline-external-thunk,+retpoline-indirect-branches,+retpoline-indirect-calls`), SLS (`+harden-sls-ijmp,+harden-sls-ret`).
* x86 32-bit: `-Zregparm=3`, `-Zreg-struct-return`.
* LoongArch: `-Zdirect-access-external-data`.
* production sanitizer flags: `-Zsanitizer=shadow-call-stack`, `-Zsanitizer=kcfi`, `-Zsanitizer-cfi-normalize-integer`.

Stabilization decisions for each flag will be made independently. We will likely take a future goal to drive some percentage of them to stabilization once RFC #3716 is implemented.
Stabilization decisions for each flag will be made independently. We will likely take a future goal to drive some percentage of them to stabilization once [RFC 3716] is implemented.
Loading