Support QNX 7.1 with io-sock+libstd and QNX 8.0 (no_std only)

[flba-eb]

Changes of this pull request:

1. Refactor code for qnx nto targets to share more code in file nto_qnx.rs

2. Add support for an additional network stack on nto qnx 7.1.

   QNX 7.1 supports two network stacks:

   1. io-pkt, which is default
   2. io-sock, which is optional on 7.1 but default in QNX 8.0

   As one can see in the io-sock migration notes, this changes the libc API in a way similar to e.g. linux-gnu vs. linux-musl.

   This change adds a new target which has a different value for target_env, so that e.g. libc can distinguish between both APIs.

3. Add initial support for QNX 8.0, thanks to AkhilTThomas. As it turned out, the problem with forking many processes still exists in QNX 8.0. Because if this, we are now using it for any QNX version (i.e. not check for target_env anymore).

@rustbot label +O-neutrino
CC: @jonathanpallant @japaric @gh-tr @AkhilTThomas

[rustbot]

r? @pnkfelix

rustbot has assigned @pnkfelix.
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

[jonathanpallant]

So, first up, excellent! The AWS QNX Neutrino 7.1.0 AMIs appears to use iosock and so I have to keep copying over libsocket.so.3 to run Rust code there. With this change hopefully I won't.

However, I note that there are currently no five-part-triples in the target list, so this would be the first. Perhaps aarch64-unknown-nto-qnx710_iosock would be better.

Will there be a x86_64-unknown-nto-qnx710_iosock to match?

[flba-eb]

So, first up, excellent! The AWS QNX Neutrino 7.1.0 AMIs appears to use iosock and so I have to keep copying over libsocket.so.3 to run Rust code there. With this change hopefully I won't.

Beware that version 3 and 4 have different APIs -- they may seem to work, but there might be subtle issues up to undefined behavior.

However, I note that there are currently no five-part-triples in the target list, so this would be the first. Perhaps aarch64-unknown-nto-qnx710_iosock would be better.

Very good idea -- I found it confusing that target_env uses an underscore while the target name does not. I will rename it!

Will there be a x86_64-unknown-nto-qnx710_iosock to match?

Not planned so far, but should be quite easy to do. How big is the need for it?

[jonathanpallant]

How big is the need for it?

No idea. Who was asking for this target?

[jonathanpallant]

I was thinking to use an obvious dummy value rather than panicking if the environment variable isn't set. But maybe the project people have a better idea.

Are there another other targets that need to read environment variables?

[elahav]

What is the problem with forking many processes? How many is "many"? QNX supports up to 4094 simultaneous processes (procnto takes 1, so that's 4093), each with up to 32K threads. Are you really hitting a limit?

[flba-eb]

@elahav : Are you referring to the changed comment in file library/std/src/sys/pal/unix/process/process_unix.rs? If you have read the comment and the linked page, what exactly is unclear, how can we improve it? We do not hit a limit.

[elahav]

I was just looking at the description of the MR, which says "As it turned out, the problem with forking many processes still exists in QNX 8.0". I went to the file you mentioned, and the comment is indeed clear. The code was changed in 8.0 to ignore EBADF on file duplication during fork(). While it is still a user error, we decided it's better to let the fork() succeed. Of course, you won't be able to predict whether the fd being changed from another thread is open in the child.

Did you run into the problem, or is it just based on the documentation? If so, it's possible the documentation is out of date.

[flba-eb]

The problem was reliably reproducible with 7.1 when running the test suite of Rusts stdlib (which forks a lot of processes with high frequency, one process per test case). I never tested that on 8.0 without our workaround. We changed the comment based on the documentation of 8.0. Do you think this should be fixed in 8.0 or could the behavior have change which would require a change in Rusts stdlib?

[elahav]

You can keep the loop if it makes it easier to have common code between 7.1 and 8.0. It should not be needed, but it doesn't do any harm.

Note that posix_spawn() can still return EBDAF for reasons mentioned by POSIX.