Retroactive MCP for the Rust for Linux Ecosystem Test Job

[jieyouxu]

Proposal

Retroactive MCP for the x86_64-rust-for-linux ecosystem test job as per Adding ecosystem/integration test jobs/components to rust-lang/rust CI. This was co-authored with @Darksonn and @ojeda.

Test job/component rationale

What does this test job/component do?

• If an ecosystem test job/component is being proposed, can you briefly describe the intended
  ecosystem users?

Rust for Linux (RfL) is the project adding support for the Rust language to the Linux kernel.

It is an ecosystem integration test where a stage 1 sysroot is built to try to compile several Rust for Linux drivers and examples to detect significant breakages/changes that would be observed by RfL.

What rust-lang/rust changes can potentially break the test job/component?

E.g. changes to rustc, standard library, bootstrap or tools (like clippy/rustfmt/cargo).

All.

Why does this test job/component need to be part of the rust-lang/rust PR and/or Full Merge CI?

Rust and Rust for Linux hope to avoid unintentional changes to Rust that break the kernel. In other words, apart from intentional changes on Rust's side, upcoming Rust versions should generally be able to build the Linux kernel.

If the test job/component will block on failure, why does it need to block?

It needs to block in order to ensure that the Linux kernel is buildable (at least, the basic subset/configuration being tested so far). Nevertheless, sometimes breakage may need to be fixed on either side (Rust or Linux), or the CI may need to be disabled.

If the test job/component will not block on failure initially but is intended to eventually become
blocking:

• Why will it become blocking?
• When will it become blocking?

N/A. This job is already blocking Full Merge CI.

Test job/component maintainers

The proposed test job/component for rust-lang/rust CI must have at least one dedicated test
job/component maintainer. The test job/component maintainers understand that they will be pinged
or otherwise contacted about the ecosystem/integration test job/component, particularly for (but
not limited to) its failures.

Please list who will be maintaining this ecosystem/integration test job/component here. Please
format the github handles in the style:

[@github_handle_1](https://github.com/github_handle_2)
[@github_handle_2](https://github.com/github_handle_2)

NOTE: For future readers, you can paste the usernames without formatting them as links via
ctrl-shift-v.

@alex
@bjorn3
@dakr
@Darksonn
@dingxiangfei2009
@fbq
@maurer
@metaspace
@nbdd0121
@ojeda
@tgross35
@vincenzopalazzo
@y86-dev

You can also contact RfL maintainers through the triagebot ping group

@rustbot ping rfl

NOTE: If an ecosystem/integration test job/component no longer has an active dedicated
maintainer (or maintainers), and if rust-lang/rust teams find the ecosystem/integration test
job/component causes significant burden or becomes irrelevant, then the ecosystem/integration test
job/component may be removed.

Understood.

CI infrastructure considerations

You should ask the Infrastructure Team on the
#t-infra zulip channel when
proposing a new ecosystem/integration test job/component to check if there's capacity for the test
job/component.

• Does the ecosystem/integration test job/component require substantial CI resources (storage and/
  or CI time)? In particular, will it require large runners?

N/A. Already in Full Merge CI.

Features and implementation details

Does the proposed test job/component intend to use any unstable features?

• If so, are the unstable features ready for exposure (e.g. must an unstable feature be completely reworked)?
• For ecosystem test jobs/components, are the unstable features ready for such exposure to the ecosystem, and are the feature stakeholders ready for such usage?

Yes. Linux is in regular contact with the Rust project about which unstable features are used. New features are only added after communication with the Rust project.

Does the proposed test job/component intend to intentionally depend on any implementation details? This may include but is not limited to: unstable/internal compiler/tool flags and behaviors, RUSTC_BOOTSTRAP usages, standard library implementation details, etc.

• If so, are there plans to shrink or expand such dependencies in the future?

Yes, Linux currently uses a set of unstable features (including language, compiler, rustdoc, etc.). See https://rust-for-linux.com/unstable-features and Rust-for-Linux/linux#2.

However, Rust and Rust for Linux are working towards stabilizing those features (or otherwise finding alternative approaches). See the related Rust flagship goals of 2024H2 and 2025H1.

In particular, at the time of writing (mid 2025), only a couple unstable language features remain in use. It is expected that they become stable after blockers are resolved. There may be new language unstable features in the future that could become useful for Linux (e.g. native pin-init, field projections, features to help with the orphan rules, features to help writing a custom alloc that is on par with the standard library one...).

On the other hand, there are still a fair amount of unstable compiler flags and other features in use in certain configurations, including building core manually (by calling directly rustc on it) as well as a custom compiler-builtins and a custom target specification file (target.json) for x86. It is expected that many of them will become stable, but it is also likely that Linux will need new compiler unstable features (flags) in the future, as more architectures, configurations, sanitizers, hardware, new compiler features, etc. are supported.

Linux uses RUSTC_BOOTSTRAP so that it can be built with stable releases of Rust, including toolchains provided by Linux distributions.

Failure protocol: what to do if the job/component breaks/fails?

NOTE: If the artifacts of an ecosystem/integration test job/component are not shipped as part of
a distribution component/toolchain, the test job/component may be temporarily disabled to unblock
rust-lang/rust PR CI or Full Merge CI without receiving prior approval from the test
job/component maintainers. The test job/component maintainers will be pinged or otherwise notified
about the test job/component being disabled.

Understood.

How can the test job/component maintainers be contacted in case of failure? By default, it is
assumed that the test job/component maintainer can be pinged via their GitHub handles.

Through github handles listed previously, and through the triagebot ping group

@rustbot ping rfl

(If applicable) If the addition of an ecosystem/integration test job is being proposed:

• How can the test job be run in CI? If so, is there a try job (try-job: ...) invocation? What's
  the job name?
• Can the test job be run locally? If so, how?

• The x86_64-rust-for-linux CI job can be run on a PR through try-job: x86_64-rust-for-linux.
• To build Linux locally with a modified rustc, start by creating your custom toolchain, add the toolchain to your path, and follow the instructions from the Documentation/rust/quick-start.rst file in the Linux kernel repository. Ping the RfL maintainers for help.

(If applicable) If the addition of an ecosystem/integration test component is being proposed:

• Which existing CI jobs will be building and testing this test component?
• Can they be built and ran as part of a try job? If so, what are the job names and the try job
  (try-job: ...) invocations?
• Can the test component be built and run locally? If so, how?

N/A

How can the test job/component be disabled in the event of spurious failures that are blocking PR
and/or Full Merge CI?

Comment out the x86_64-rust-for-linux test job in src/ci/github-actions/jobs.yml, and ping the RfL maintainers on the PR.

If a PR breaks the test job/component:

• If the breakage seems spurious and retrying does not resolve the spurious breakage, the test
  job may be temporarily disabled (see below).
• If the breakage is intentional, how will this be resolved?
• If the breakage is unintentional, is the PR author expected to fix the breakage?

If a PR breaks the Rust for Linux CI job, then:

• If the breakage was unintentional and seems spurious, then let RfL
  know (through @rustbot ping rfl) and retry.
  • If the PR is urgent and retrying doesn't fix it, then disable the CI job
    temporarily (comment out the image: x86_64-rust-for-linux job in
    src/ci/github-actions/jobs.yml).
• If the breakage was unintentional, then change the PR to resolve the breakage.
• If the breakage was intentional, then let RfL know and discuss
  what will the kernel need to change.
  • If the PR is urgent, then disable the CI job temporarily (comment out
    the image: x86_64-rust-for-linux job in src/ci/github-actions/jobs.yml).
  • If the PR can wait a few days, then wait for RfL maintainers to provide a
    new Linux kernel commit hash with the needed changes done, and apply it to
    the PR, which would confirm the changes work (update the LINUX_VERSION
    environment variable in src/ci/docker/scripts/rfl-build.sh).
  • You are not required to fix Linux yourself. If changes are needed,
    then the RfL maintainers will make them for you.

Dependencies, build/test environments and reliability

Does the test job/component involve any custom build systems that are not used in the regular
rust-lang/rust CI jobs?

The Linux kernel is built using Kbuild (make).

Does the test job/component depend on external resources (e.g. external servers) that may be
subject to network connectivity?

• If so, does the infrastructure team need to help maintain a mirror of the required assets?

The job depends on the Linux kernel source code, which can be obtained from GitHub or git.kernel.org. A mirror is not needed. The RfL maintainers can provide patched kernels when a workaround is needed on the Linux side (see above).

Are there any potential sources of spurious failures due to the test job/component?

Cloning the Linux kernel source code could fail due to network errors. Nevertheless, at the moment the clone comes from GitHub.

Are there any other unusual requirements (build environment, dependencies, etc.)?

It depends on make and various tools to build C code. The shell script sets this up.

Mentors or Reviewers

Anyone from compiler.

Process

The main points of the Major Change Process are as follows:

• File an issue describing the proposal.
• A compiler team member or contributor who is knowledgeable in the area can second by writing @rustbot second.
  • Finding a "second" suffices for internal changes. If however, you are proposing a new public-facing feature, such as a -C flag, then full team check-off is required.
  • Compiler team members can initiate a check-off via @rfcbot fcp merge on either the MCP or the PR.
• Once an MCP is seconded, the Final Comment Period begins. If no objections are raised after 10 days, the MCP is considered approved.

You can read more about Major Change Proposals on forge.

[rustbot]

Important

This issue is not meant to be used for technical discussion. There is a Zulip stream for that.
Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

Concerns or objections can formally be registered here by adding a comment.

@rfcbot concern reason-for-concern
<description of the concern>

Concerns can be lifted with:

@rfcbot resolve reason-for-concern

See documentation at https://forge.rust-lang.org

cc @rust-lang/compiler