Re-organized the QNX support.

[jonathanpallant]

Description

As most of the differences are related to the change in network stack half-way through the life of QNX Neutrino 7.1, the definitions are now split into io-pkt (the older stack) and io-sock (the newer stack).

I didn't add any architecture definitions for x86 (as would be required for i686-pc-nto-qnx700) because I don't have access to QNX Neutrino 7.0 to verify what should go here. But there's a clear place to add it later.

I do have QNX Neutrino 7.1 and QNX OS 8.0 and I have verified each of the types in the io-pkt and io-sock modules against the relevant C header files. I have not verified the remaining types or functions - I assume they are correct.

This is an alternative to #4615, which seems to have stalled.

Sources

For io-sock, QNX says:

The io-sock networking stack supports all the routines that application programmers would expect, including (but not limited to) the functions listed below. The FreeBSD 13.5 manual pages at https://www.freebsd.org/cgi/man.cgi are the best guide to their use:

For io-pkt, you can refer to https://www.qnx.com/developers/docs/7.1/.

Checklist

• Relevant tests in libc-test/semver have been updated
  • There aren't any for QNX
• No placeholder or unstable values like *LAST or *MAX are included (see #3131)
  • I left all the existing ones
• Tested locally (cd libc-test && cargo test --target mytarget); especially relevant for platforms that may not be checked in CI
  • I tried running this locally and I got: not implemented: Foreign functions are unlikely to have any other pattern. I don't know if we normally run the tests for this target.

[jonathanpallant]

Force push some formatting fixes.

[jonathanpallant]

I tried to tell bootstrap to use this libc, but this repo has 1.0.0-something and my rust source build wants libc 0.2, so it ignored the patch.crates-io entry. If anyone has any advice on how to build a libstd for QNX using this, I'd be happy to try.

[jonathanpallant]

I rebased these changes onto the libc-0.2 branch, built a libstd for AArch64 QNX 7.1 with io-sock, built some test programs that do threading and networking, sent to them an AArch64 QNX Neutrino 7.1 instance on AWS, and they worked OK. So I'm fairly confident I've not broken anything catastrophically.

I can send the libc-0.2 PR once this is merged, if that's useful.

[tgross35]

Do io_pkt and io_sock match up with specific headers or directories? If so, they can go in src/new/nto which is where we're migrating files that closer match up with source. (Ideally also add a tag like //! Header: uapi/linux/can.h` to make it easy to match up). You can re-order things to be in the same order as the source headers too if it's easier to follow.

I assume neutrino.rs could probably also move here

[jonathanpallant]

There are two trees, one for io-pkt and one for io-sock. They contain files with the same names, and the file contents are similar but slightly different.

I guess there's a trade-off between having the Rust code faithfully match the C headers, but with a lot of duplication. Or, as I have done here, have one Rust file that covers all the common elements, and then have only their differences pulled out to their own files.

[tgross35]

I'm sorry this has been sitting for such a long amount of time, we've been stretched on review power for a little while. This will need a rebase but I have no concerns here.

An optional change, if you're interested, is to move arch/*, io_pkt, io_sock, and neutrino.rs to src/new/nto since I believe those modules are well-organized at this point. Otherwise I can do it later.

@rustbot author for the rebase

View changes since this review

[rustbot]

Reminder, once the PR becomes ready for a review, use @rustbot ready.

[jonathanpallant]

I'll leave the moving around of files for another time, because with rust-lang/rust#158449 we might want to do something different.

Looking at the rebase now.

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[jonathanpallant]

I'm having a bit of trouble running ci/style.py locally because my Linux is quite old (Kernel 5.15) and some CAN_xxx constants are missing?

But I think I worked out it wanted the imports at the bottom of the file, not the top.

[tgross35]

I need to fix the style tests so they don't run ctest, that's kind of silly (artifact of ctest mostly happening in build scripts), but LGTM. Thanks!