consider disallowing setting target_family if target_os=none

[ehuss]

Should setting target_family require also setting target_os?

Currently, the x86_64-linux-kernel target 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 writing cfg expressions 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 cfg settings.

This issue came up during #74033 where I was adjusting some cfg expressions for building std for Cargo. I do not know if Cargo's build-std will ever support x86_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:

Does the Linux kernel even have an UNIX API inside of itself? That doesn't sound right but maybe I just haven't seen it before.

(To be clear, I'm thinking that family="unix" is as valid for inside an OS kernel as os="thatosname" - if os="none" is used then surely there should also not be a family? Maybe we should enforce that the family is derived from the OS name and therefore means "OS family")

cc @joshtriplett who I think might know a little about the x86_64-linux-kernel target, and @alex who introduced the target. Perhaps they can shed some light why "unix" was chosen.

[joshtriplett]

@ehuss Given that the target will not be able to use the vast majority of std, I don't know if it makes sense to use unix, as opposed to some kind of embedded no-os target.

@alex, @geofft, any thoughts? Is there a good reason to use unix here?

[alex]

Hmmm, I don't remember why unix was chosen, it's entirely possible it was a bad cargo-cult.

The target currently does work with build-std in cargo, so ideally that wouldn't regress :-)

In short, simply setting target_family=none seems most obviously correct to me.

[joshtriplett]

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?

[alex]

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 <notifications@github.com> 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.

[alex]

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.

[joshtriplett]

@alex Could you send a PR to that effect, CCing @ehuss and myself, and we can review and approve it?

[alex]

Yeah, I can do that.

[nagisa]

Side note, I find the target string itself malformed, if we don't end up setting target_os=linux for this target. To me the target string was always arch-vendor-os-env, and in my head this really parses as arch=x86_64, os=linux, env=kernel rather than arch=x86_64, os=none, env=linux-kernel, which is what this target is.

---

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]

@alex was #74257 meant to point to this issue? It points to #72314 instead which I don't see how it's related.

[alex]

@eddyb yes, it was. No idea how that happened.