Change built-in kernel targets to be os = none throughout #77916

Ericson2314 · 2020-10-13T20:58:37Z

Whether for Rust's own target_os, LLVM's triples, or GNU config's, the
OS-related have fields have been for code running on that OS, not code
hat is part of the OS.

The difference is huge, as syscall interfaces are nothing like
freestanding interfaces. Kernels are (hypervisors and other more exotic
situations aside) freestanding programs that use the interfaces provided
by the hardware. It's those interfaces, the ones external to the
program being built and its software dependencies, that are the content
of the target.

For the Linux Kernel in particular, target_env: "gnu" is removed for
the same reason: that -gnu refers to glibc or GNU/linux, neither of
which applies to the kernel itself.

Relates to #74247

rust-highfive · 2020-10-13T20:58:40Z

r? @lcnr

(rust_highfive has picked a reviewer for you, use r? to override)

compiler/rustc_target/src/spec/x86_64_unknown_none_linuxkernel.rs

lcnr · 2020-10-14T07:35:42Z

maybe r? @Mark-Simulacrum

kloenk

Those names sounds much better

bors · 2020-10-15T19:34:34Z

☔ The latest upstream changes (presumably #77943) made this pull request unmergeable. Please resolve the merge conflicts.

Note that reviewers usually do not review pull requests until merge conflicts are resolved! Once you resolve the conflicts, you should change the labels applied by bors to indicate that your PR is ready for review. Post this as a comment to change the labels:

@rustbot modify labels: +S-waiting-on-review -S-waiting-on-author

Mark-Simulacrum · 2020-10-15T20:06:07Z

Tentatively r? @joshtriplett

Ericson2314 · 2020-10-15T20:46:29Z

Per the issue thread (just to make things easier for anyone just reading the PR), While I prefer this to the status quo, my first preference is removing these targets outright. having per-project targets baked into rustc seems like a layer violation and maintenance hazard anyways.

joshtriplett · 2020-10-18T03:05:30Z

LGTM.

r=me when ready.

joshtriplett · 2020-10-18T03:09:05Z

@Ericson2314 I understand what you mean by a "layering violation", but given that we don't have stable support for custom targets, and given that it seems extremely unlikely we'll stabilize that because it's so dependent on specific details of LLVM internals, I think we need to have at least minimal scaffolding for important specialized targets.

We also don't have full support for building std/core from source yet, let alone for replacing it with a crate from the ecosystem.

Right now, there really isn't any path towards stable support for such targets without at least some infrastructure-level support like this.

I'm not suggesting that we should have targets specific to using Rust as a plugin to arbitrary specific pieces of software, but the Linux kernel is a very popular and desirable target to be able to run Rust in, and it provides enough infrastructure that substantial portions of the standard library (including alloc and a fair bit of std) would work.

Ericson2314 · 2020-10-20T04:49:50Z

@joshtriplett This was the main thing we discussed on the call.

It's my understanding that the plan for the -z build-std work to stabilize without needing to stabilizing any of the language features we need to build standard library crates.

How might this work? The tools merely need to authenticate that the crates being built are in fact the officials stdlib crates, and unlock the nightly features only for that code. Then there's no risk of user code using things it shouldn't.

It was also discussed that given how the timeline LLVM Linux work as progressed, there ought to be be plenty of runway to be on Nightly until such functionality is worked out if Rust is held to the same standard.

Dylan-DPC-zz · 2020-11-24T16:56:53Z

@Ericson2314 any updates? also you have a few conflicts to resolve

ojeda · 2020-11-26T21:49:03Z

given that it seems extremely unlikely we'll stabilize that because it's so dependent on specific details of LLVM internals

I don't think users in the freestanding world would mind if the target spec options themselves are documented to not be compatible between Rust releases. Being able to use a stable release of the compiler in such environments is usually way more important.

Ericson2314 · 2020-12-02T16:08:56Z

OK the merge conflicts are fixed. I would still advocate for these targets to be removed, but I think merging this PR is still a (less controversial) improvement over the status quo, so happy if we start with that and return to the question of removal after.

compiler/rustc_target/src/spec/x86_64_unknown_none_linuxkernel.rs

compiler/rustc_target/src/spec/mod.rs

library/unwind/src/lib.rs

compiler/rustc_target/src/spec/x86_64_unknown_none_linuxkernel.rs

Dylan-DPC-zz · 2021-03-01T23:41:27Z

@bors r=joshtriplett

bors · 2021-03-01T23:41:28Z

📌 Commit 9d25ccf has been approved by joshtriplett

…, r=joshtriplett Change built-in kernel targets to be os = none throughout Whether for Rust's own `target_os`, LLVM's triples, or GNU config's, the OS-related have fields have been for code running *on* that OS, not code hat is *part* of the OS. The difference is huge, as syscall interfaces are nothing like freestanding interfaces. Kernels are (hypervisors and other more exotic situations aside) freestanding programs that use the interfaces provided by the hardware. It's *those* interfaces, the ones external to the program being built and its software dependencies, that are the content of the target. For the Linux Kernel in particular, `target_env: "gnu"` is removed for the same reason: that `-gnu` refers to glibc or GNU/linux, neither of which applies to the kernel itself. Relates to rust-lang#74247

bors · 2021-03-03T13:46:06Z

⌛ Testing commit 9d25ccf with merge cc8aa2c31407e3a9c742ab7f865e8820cc104379...

bors · 2021-03-03T18:01:06Z

💥 Test timed out

rust-log-analyzer · 2021-03-03T18:07:21Z

A job failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

##[group]Virtual Environment
Environment: ubuntu-20.04
Version: 20210302.0
Included Software: https://github.com/actions/virtual-environments/blob/ubuntu20/20210302.0/images/linux/Ubuntu2004-README.md
Image Release: https://github.com/actions/virtual-environments/releases/tag/ubuntu20%2F
##[group]GITHUB_TOKEN Permissions
Actions: write
Checks: write
Contents: write

JohnTitor · 2021-03-06T21:08:33Z

@bors retry

…, r=joshtriplett Change built-in kernel targets to be os = none throughout Whether for Rust's own `target_os`, LLVM's triples, or GNU config's, the OS-related have fields have been for code running *on* that OS, not code hat is *part* of the OS. The difference is huge, as syscall interfaces are nothing like freestanding interfaces. Kernels are (hypervisors and other more exotic situations aside) freestanding programs that use the interfaces provided by the hardware. It's *those* interfaces, the ones external to the program being built and its software dependencies, that are the content of the target. For the Linux Kernel in particular, `target_env: "gnu"` is removed for the same reason: that `-gnu` refers to glibc or GNU/linux, neither of which applies to the kernel itself. Relates to rust-lang#74247

Rollup of 13 pull requests Successful merges: - rust-lang#77916 (Change built-in kernel targets to be os = none throughout) - rust-lang#82130 (Make some Option, Result methods unstably const) - rust-lang#82292 (Prevent specialized ZipImpl from calling `__iterator_get_unchecked` twice with the same index) - rust-lang#82402 (Remove RefCell around `module_trait_cache`) - rust-lang#82592 (Improve transmute docs with further clarifications) - rust-lang#82651 (Cleanup rustdoc warnings) - rust-lang#82720 (Fix diagnostic suggests adding type `[type error]`) - rust-lang#82751 (improve offset_from docs) - rust-lang#82793 (Move some tests to more suitable subdirs) - rust-lang#82803 (rustdoc: Add an unstable option to print all unversioned files) - rust-lang#82808 (Sync rustc_codegen_cranelift) - rust-lang#82822 (Fix typo) - rust-lang#82837 (tweak MaybeUninit docs) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup

rust-highfive assigned lcnr Oct 13, 2020

rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Oct 13, 2020

Aaron1011 reviewed Oct 13, 2020

View reviewed changes

compiler/rustc_target/src/spec/x86_64_unknown_none_linuxkernel.rs Outdated Show resolved Hide resolved

Ericson2314 force-pushed the kernel-code-targets-os-none branch from 0ea520b to b93c597 Compare October 13, 2020 21:13

Ericson2314 mentioned this pull request Oct 13, 2020

consider disallowing setting target_family if target_os=none #74247

Open

alex mentioned this pull request Oct 13, 2020

Prepare to change target logic Rust-for-Linux/linux#25

Closed

rust-highfive assigned Mark-Simulacrum and unassigned lcnr Oct 14, 2020

kloenk approved these changes Oct 14, 2020

View reviewed changes

Ericson2314 force-pushed the kernel-code-targets-os-none branch from b93c597 to 86d860e Compare October 14, 2020 19:05

rust-highfive assigned joshtriplett and unassigned Mark-Simulacrum Oct 15, 2020

rust-lang deleted a comment from bors Oct 18, 2020

crlf0710 added I-needs-decision Issue: In need of a decision. S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Nov 6, 2020

ojeda reviewed Dec 2, 2020

View reviewed changes

Ericson2314 commented Dec 2, 2020

View reviewed changes

compiler/rustc_target/src/spec/x86_64_unknown_none_linuxkernel.rs Outdated Show resolved Hide resolved

Ericson2314 force-pushed the kernel-code-targets-os-none branch from feedaa0 to b71a5a9 Compare December 2, 2020 22:32

Ericson2314 force-pushed the kernel-code-targets-os-none branch from 4bab995 to 9d25ccf Compare March 1, 2021 17:46

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Mar 1, 2021

bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Mar 3, 2021

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Mar 6, 2021

Dylan-DPC-zz mentioned this pull request Mar 6, 2021

Rollup of 10 pull requests #82847

Closed

JohnTitor mentioned this pull request Mar 7, 2021

Rollup of 13 pull requests #82851

Merged

bors merged commit d1dc166 into rust-lang:master Mar 7, 2021

rustbot added this to the 1.52.0 milestone Mar 7, 2021

Ericson2314 deleted the kernel-code-targets-os-none branch April 16, 2021 21:50

mkroening mentioned this pull request Jul 17, 2021

Rename to x86_64-unknown-none-hermitkernel hermit-os/rftrace#11

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Change built-in kernel targets to be os = none throughout #77916

Change built-in kernel targets to be os = none throughout #77916

Ericson2314 commented Oct 13, 2020 •

edited

Loading

rust-highfive commented Oct 13, 2020

lcnr commented Oct 14, 2020

kloenk left a comment

bors commented Oct 15, 2020

Mark-Simulacrum commented Oct 15, 2020

Ericson2314 commented Oct 15, 2020

joshtriplett commented Oct 18, 2020 •

edited

Loading

joshtriplett commented Oct 18, 2020

Ericson2314 commented Oct 20, 2020 •

edited

Loading

Dylan-DPC-zz commented Nov 24, 2020

ojeda commented Nov 26, 2020

Ericson2314 commented Dec 2, 2020

Dylan-DPC-zz commented Mar 1, 2021

bors commented Mar 1, 2021

bors commented Mar 3, 2021

bors commented Mar 3, 2021

rust-log-analyzer commented Mar 3, 2021

JohnTitor commented Mar 6, 2021

Change built-in kernel targets to be os = none throughout #77916

Change built-in kernel targets to be os = none throughout #77916

Conversation

Ericson2314 commented Oct 13, 2020 • edited Loading

rust-highfive commented Oct 13, 2020

lcnr commented Oct 14, 2020

kloenk left a comment

Choose a reason for hiding this comment

bors commented Oct 15, 2020

Mark-Simulacrum commented Oct 15, 2020

Ericson2314 commented Oct 15, 2020

joshtriplett commented Oct 18, 2020 • edited Loading

joshtriplett commented Oct 18, 2020

Ericson2314 commented Oct 20, 2020 • edited Loading

Dylan-DPC-zz commented Nov 24, 2020

ojeda commented Nov 26, 2020

Ericson2314 commented Dec 2, 2020

Dylan-DPC-zz commented Mar 1, 2021

bors commented Mar 1, 2021

bors commented Mar 3, 2021

bors commented Mar 3, 2021

rust-log-analyzer commented Mar 3, 2021

JohnTitor commented Mar 6, 2021

Ericson2314 commented Oct 13, 2020 •

edited

Loading

joshtriplett commented Oct 18, 2020 •

edited

Loading

Ericson2314 commented Oct 20, 2020 •

edited

Loading