Fix target_os for mipsel-sony-psx

[madsmtm]

Previously set to target_os = "none" and target_env = "psx" in the PR introducing the target, but although the Playstation 1 is close to a bare metal target in some regards, it's still very much an operating system, so we should instead set target_os = "psx".

This also matches the mipsel-sony-psp target, which sets target_os = "psp".

CC target maintainer @ayrtonm.

If there's any code out there that uses cfg(target_env = "psx"), they can use cfg(any(target_os = "psx", target_env = "psx")) until they bump their MSRV to a version where this is fully fixed.

[rustbot]

r? @davidtwco

rustbot has assigned @davidtwco.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[rustbot]

These commits modify compiler targets.
(See the Target Tier Policy.)

[ayrtonm]

Since PS1 doesn't support std this PR doesn't really change much so it's not a huge deal. However, I don't think it should be changed and this statement seems wrong to me.

although the Playstation 1 is close to a bare metal target in some regards, it's still very much an operating system

Also the differences from the PSP target were intentional given what I saw the rust psp sdk does. I don't have time to get into it now, but I'll follow up with my rationale later today or tomorrow.

[madsmtm]

No problem, you're much more involved in the details here than I am!

I will say though, if we do not do this change, then the target should perhaps be renamed to mipsel-sony-none-psx? Though I get that that may be disruptive.

I'll leave this PR open, both to allow the discussion to continue, and because I intend to document the final rationale in the code, but to prevent it from being merged, lets do:
@rustbot blocked

[workingjubilee]

feels like a bootloader with some firmware, tbh: https://psx.arthus.net/sdk/Psy-Q/DOCS/Devrefs/os.pdf

guess you could call that an exokernel?

[rustbot]

Some changes occurred in tests/ui/check-cfg

cc @Urgau

[ayrtonm]

So the line between operating system and bare metal is blurry here. Basically it does have a thing called a BIOS but it's more of a loader than useful for anything that an OS does. Specifically:

1. it leaves the mips coprocessor bits for kernel/user mode in kernel mode when loading user code and iirc those cop0r12 bits don't do anything on it anyway
2. it doesn't do any thread scheduling
3. there's no MMU so the 64K of RAM it sets up can be completely overwritten by other code
4. calling back into the BIOS doesn't use syscalls for the most part. It expects user code to use jump instructions to make use of three "exception vectors" it sets up in some of its RAM
5. it doesn't mediate access to any hardware, so anything it provides access to can be done through mmio by other code (and that's typically the case with homebrew SDKs)

The one point for target_os = "psx" is that the portion of the BIOS that's in ROM is always resident in the phyical address space (because it's read-only). I think there's also one function that only the BIOS can do because it has to be done from code running in ROM (it involves caches but the details escape me at the moment).

Imho since it doesn't use syscalls for most of the functions it provides and running BIOS/user code doesn't have appreciable differences in terms of what that code is allowed to do (especially for the code it relocates to RAM) target_os = none seems more accurate to me. That's why it differs from the PSP target even though they have similar names. If there's a strong reason for changing it I don't think there's an issue either way.

I will say though, if we do not do this change, then the target should perhaps be renamed to mipsel-sony-none-psx? Though I get that that may be disruptive.

I'd really like to avoid that if possible, that kind of user-facing instability defeats the purpose of having the target in tree :/

[workingjubilee]

Imho since it doesn't use syscalls for most of the functions it provides

fwiw I don't think we necessarily define an OS as "something you do syscalls to", as odd as that may sound. e.g. the hermit target is a unikernel (so the "OS" and application are all compiled as one thing!) but we put the name in target_os all the same, because

1. no other target_os applies, obviously
2. the particular quirks of how it is "not an OS" define the target for every sense an OS would define the target, even if by the way it inverts it

no strong opinion on whether that applies to this target, tho', just noting for reference.

[ayrtonm]

yeah unikernels are a good point @workingjubilee. I realized after my last comment that another counter-example is linux which is obviously an OS, but provides functions w/o syscalls through vdso. Either way defining what counts as an OS is fuzzy but if this change makes it easier to do the target parsing stuff for cc-rs then that's good enough for me @madsmtm.

[ayrtonm]

@rustbot ready

[madsmtm]

Thanks a lot for explaining your reasoning! I've tried to add a quick comment summarizing it, though not too happy with how it turned out, if you want to review the wording here that'd be nice.

Overall, I still have a preference for merging this PR, but ultimately, I'll leave it to the T-compiler reviewer to decide whether they want target_os = "psx" or target_env = "psx".

if this change makes it easier to do the target parsing stuff for cc-rs

I think we're gonna go a different approach, so doesn't matter too much for cc, mostly opened this PR to fix what I perceived as an inconsistency.

[ayrtonm]

I think we're gonna go a different approach, so doesn't matter too much for cc, mostly opened this PR to fix what I perceived as an inconsistency.

If you don't need this for anything you're doing (either using the target or not) I have a slight preference for keeping it the way it was since this case is fuzzy.

[workingjubilee]

I feel like we might want to get the relevant Nintendo and PlayStation people in a room and hash out how we want to handle talking about console compilation and runtime environments in the compiler at some point, but it doesn't seem best decided in this PR.

[davidtwco]

I don't have a strong opinion on this because it's the Playstation 1 target, but I was chatting to @wesleywiser about this at EuroRust and we think that whether or not we set target_os could depend on whether or not Rust calls into this OS or not, and given that Rust on this target does not do that, it shouldn't have an target_os (e.g. you could compile with our bare-metal x86_64 target and run that on something with an OS, and make the syscalls yourself, but that doesn't mean the target should have target_os set).

But like I said, it's the Playstation 1 target, so I have the weakest possible opinion on this, and if @ayrtonm is happy with this patch as the target maintainer, then I'm happy to r+ it.

[ayrtonm]

yeah the change in this PR is fine with me.

set target_os could depend on whether or not Rust calls into this OS or not

This sounds like a reasonable approach though it's not clear to me if 'Rust' here refers to just core/std or any Rust code.

[davidtwco]

This sounds like a reasonable approach though it's not clear to me if 'Rust' here refers to just core/std or any Rust code.

core/std

[davidtwco]

But since you're happy with this change, I'll approve this.

@bors r+ rollup

[bors]

📌 Commit afe6059 has been approved by davidtwco

It is now in the queue for this repository.