consider disallowing setting target_family if target_os=none #74247
Comments
|
Hmmm, I don't remember why The target currently does work with In short, simply setting |
|
On Sat, Jul 11, 2020 at 01:32:12PM -0700, Alex Gaynor wrote:
The target currently _does_ work with `build-std` in `cargo`, so ideally that wouldn't regress :-)
Interesting! Are you actually building `std`, or just `core` and
`alloc`? Are there any `cfg(unix)` or `cfg(... = "unix")` conditionals
that this is actually affecting?
|
|
Just core and alloc. No way to run `std` inside the kernel :-)
I can't imagine there's any cfg unix conditionals its impacting, but I
guess I never checked. I'll do some quick greps over liballoc and libcore.
On Sat, Jul 11, 2020 at 4:34 PM Josh Triplett <[email protected]>
wrote:
… On Sat, Jul 11, 2020 at 01:32:12PM -0700, Alex Gaynor wrote:
> The target currently _does_ work with `build-std` in `cargo`, so ideally
that wouldn't regress :-)
Interesting! Are you actually building `std`, or just `core` and
`alloc`? Are there any `cfg(unix)` or `cfg(... = "unix")` conditionals
that this is actually affecting?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#74247 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAAGBHEIWSYP66GZH7KQLLR3DED5ANCNFSM4OXMGL2A>
.
--
All that is necessary for evil to succeed is for good people to do nothing.
|
|
Yeah, quick grep shows there's no unix references in libcore and liballoc. So I think changing the family to none here is the right move. |
|
Yeah, I can do that. |
|
Side note, I find the target string itself malformed, if we don't end up setting More on topic, I don’t think we add targets often enough, and IMO targets are all often very unique once you go past the most common ones, to warrant restrictions like these. |
|
@eddyb yes, it was. No idea how that happened. |
don't mark linux kernel module targets as a unix environment refs rust-lang#74247 r?@joshtriplett cc: @ehuss
don't mark linux kernel module targets as a unix environment refs rust-lang#74247 r?@joshtriplett cc: @ehuss
don't mark linux kernel module targets as a unix environment refs rust-lang#74247 r?@joshtriplett cc: @ehuss
don't mark linux kernel module targets as a unix environment refs rust-lang#74247 r?@joshtriplett cc: @ehuss
don't mark linux kernel module targets as a unix environment refs rust-lang#74247 r?@joshtriplett cc: @ehuss
don't mark linux kernel module targets as a unix environment refs rust-lang#74247 r?@joshtriplett cc: @ehuss
don't mark linux kernel module targets as a unix environment refs rust-lang#74247 r?@joshtriplett cc: @ehuss
|
Re @nagisa, I could be convinced that the target should really be named For what it's worth, the actual Clang build of the kernel uses regular x86_64-linux-gnu as the triple, but as far as I can tell, that's because Clang target triples encode a lot less information than Rust target specs do - things like
Is it worth enforcing this, with a lint or something preventing libcore and liballoc from having cfg conditions on |
I believe this is already checked in https://github.com/rust-lang/rust/blob/master/src/tools/tidy/src/pal.rs |
Please! I originally wrote #64051 (comment) in quite a panic, until I was pointed to this issue. As wrote there:
Now maybe Rust has some extra metadata, like this A last thing is even the "linuxkernel" part is unnecessary, |
|
If someone fixes the discussed issues for the Linux kernel target, it would be great to fix them for |
I don't think this is actually true, as the linux kernel uses Also now noticing that the targets |
|
@DianaNites I didn't mean to say that Linux doesn't need a custom target --- just about every freestanding program does, and you rightly point out something that Linux needs that is particular to it Rather, I was trying to say that "linux" shouldn't appear as part of the contents of that target, as Linux is the program being compile, the target describes interfaces / constraints external to that program, and Linux is not external to itself. (C.f. the "don't know your own name" principle). The awkward thing is all the built-in targets that Rustc supports have names that look like LLVM targets triples, which doesn't leave anywhere to put the "linux" part except for a the end, so I'll just do |
|
I put up #77916 for the |
That is what I originally thought, but somehow Rustc got the Linux target. Each OS/kernel/platform should define whatever they need. A compiler should only need to expose the options needed to be flexible enough to work for them. |
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 that 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 Thanks @ojeda for catching some things.
…, 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
…, 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
…, 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
…, 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
|
The definition of |
|
We no longer have the linuxkernel targets so I think this is done? |
|
What about custom target JSON? It could be an error if one tries to set the family but not the OS in there? |
|
I'm going to reopen, since I think it would be a good idea to have a check for this for the future, or for things like JSON targets as mentioned. |
Should setting target_family require also setting target_os?
Currently, the
x86_64-linux-kerneltarget sets target_family to "unix", but the os is "none". This is the only target which sets the family without the os. This can make it a little confusing/awkward when writingcfgexpressions to properly cover targets such as these (sometimes the check for os="none" needs to appear before the family).In practice today this isn't an issue because libcore, liballoc, and compiler_builtins do not ever check the family. AFAIK, the family doesn't have any other effects other than the
cfgsettings.This issue came up during #74033 where I was adjusting some
cfgexpressions for building std for Cargo. I do not know if Cargo's build-std will ever supportx86_64-linux-kernel, but I'd like to try to cover as many targets as possible and avoid special cases if they are not necessary.@eddyb had some suggestions which I'll copy here:
cc @joshtriplett who I think might know a little about the
x86_64-linux-kerneltarget, and @alex who introduced the target. Perhaps they can shed some light why "unix" was chosen.The text was updated successfully, but these errors were encountered: