Adding support for QNX OS

[SebastianSchildt]

First try to enable mio to be used on QNX operating system.

Is this the right way to go about this? Once this is in acceptable form, can/should it be backported to one of the v0.8x/0.7x

We are not that familiar with mio development, so please advise.
As mio/tokio users we would appreciate if released versions just work "out of the box"

@AkhilTThomas I added you to the fork, so you can write there as well

[notgull]

Do you have any documentation of the poll syscall exposed by QNX?

[SebastianSchildt]

I am not so deep into this, so maybe @AkhilTThomas has some hands-on experience, but in terms of documentation, this is public

https://www.qnx.com/developers/docs/7.1/index.html#com.qnx.doc.neutrino.lib_ref/topic/p/poll.html

[Thomasdezeeuw]

Couple of questions:

• Can we add something to the CI, cargo test would be nice, cargo check is sufficient.
• Is annoying willing to commit to maintaining this with QNX OS knowledge? Otherwise support will not be official.

Backporting can be done after this.

[gh-tr]

Couple of comments inline surrounding SOCK_CLOEXEC.

[SebastianSchildt]

Hi, thanks for the hints. We will definitely check, although currently at least personally I am blocked not having a QNX license (anymore?). (not sure if @AkhilTThomas is better equipped currently). Working on that, but always a major pita.

I used the time to check whether something can be done with cargo check, but i think it is -without QNX toolchain installed - not possible. Do you know any way get "some level of testing" for neutrino target in an OSS project @flba-eb, as you have ported some other libs (like compiling maybe not even linking, and not running)? Or is this basically impossible currently?

[gh-tr]

Hi, thanks for the hints. We will definitely check, although currently at least personally I am blocked not having a QNX license (anymore?). (not sure if @AkhilTThomas is better equipped currently). Working on that, but always a major pita.

I used the time to check whether something can be done with cargo check, but i think it is -without QNX toolchain installed - not possible. Do you know any way get "some level of testing" for neutrino target in an OSS project @flba-eb, as you have ported some other libs (like compiling maybe not even linking, and not running)? Or is this basically impossible currently?

@flba-eb has access to a QNX license and runs checks locally; the same way I would go about it. We generally submit the test results of the crates as part of the request. I guess I'm curious why you're making changes to QNX specific code without a license. Perhaps ping me via email and we can have a quick discussion surrounding that and perhaps get you what you need?

[SebastianSchildt]

@flba-eb has access to a QNX license and runs checks locally; the same way I would go about it. We generally submit the test results of the crates as part of the request. I guess I'm curious why you're making changes to QNX specific code without a license. Perhaps ping me via email and we can have a quick discussion surrounding that and perhaps get you what you need?

Ah 2 different things: This was initially done in my company a while back, and well... as these things are it took some time being allowed to share it here. So my current lack of license is more an internal IT issue

Generally, however, as QNX support in Rust matures, I think it will be a bit of an issue, that support can break anytime. Communities like this one, most members likely have neither any contact with QNX nor do they care - which is fine, but due to the closedness it won't be easy to find any breaks eraly. I think currently it would be like this: One of the users of this (i.e. us) one day will do a cargo update, and well, figure out something broken, then come back here, trying to fix it and get it released again. In the long run, it would really be good if in the CI here upstream, there would be some way to at least compile, preferably run tests on that target.

I think we are not there yet, just thinking forward :)

[flba-eb]

Hi, thanks for the hints. We will definitely check, although currently at least personally I am blocked not having a QNX license (anymore?). (not sure if @AkhilTThomas is better equipped currently). Working on that, but always a major pita.

I used the time to check whether something can be done with cargo check, but i think it is -without QNX toolchain installed - not possible. Do you know any way get "some level of testing" for neutrino target in an OSS project @flba-eb, as you have ported some other libs (like compiling maybe not even linking, and not running)? Or is this basically impossible currently?

As @gh-tr already noted, I have a license I can use locally. Unfortunately cargo check is the best we can do right now, this is also what we're using in other crates.

[Thomasdezeeuw]

Has any progress has been made for a CI setup?

[SebastianSchildt]

So I think in the short term nothing can be done for CI. The tests do run now (think @AkhilTThomas can confirm, maybe even provide log output), if you run it locally with a toolchain set up.

There is currently no way to set up a toolchain without being a QNX customer. Also likely it is not ok for somebody to "just" set up a private runner for usage in this project based in a single seat dev license (not withstanding the question whether that is an effort/complication you even want to deal with in your CI currently)

So I would hope in the short term we can merge this on a "good faith basis", providing "as is/best effort/no guarantees" support for QNX neutrino.

In the midterm I did see some rumors QNX might become more open (https://www.linkedin.com/posts/alex-oyler_some-big-breaking-news-from-john-wall-activity-7178514730926452736-ZVqR) , so maybe the situation regarding setting up toolchains improves. I am, however, in no way affiliated with Blackberry (the current QNX owners), so I have no ideas what - if any - intentions and timeline are here.

[SebastianSchildt]

(I saw the CI still fails with clippy erros, but I think those aren't on us, are they?

[Thomasdezeeuw]

(I saw the CI still fails with clippy erros, but I think those aren't on us, are they?

No, should be fixed by #1768.

As for the CI, I think we can accept without it, but then we won't be able to support it properly. I won't really be able to judge patches as I have no way to check them. Not an ideal situation, but better than no support at all.

I think we can accept this after:

• Fixing https://github.com/tokio-rs/mio/pull/1766/files#r1538833459,
• a rebase (to fix the Clippy warnings),
• a cargo fmt run (to fix the rustfmt warnings).

[AkhilTThomas]

(I saw the CI still fails with clippy erros, but I think those aren't on us, are they?

No, should be fixed by #1768.

As for the CI, I think we can accept without it, but then we won't be able to support it properly. I won't really be able to judge patches as I have no way to check them. Not an ideal situation, but better than no support at all.

I think we can accept this after:

• Fixing https://github.com/tokio-rs/mio/pull/1766/files#r1538833459,
• a rebase (to fix the Clippy warnings),
• a cargo fmt run (to fix the rustfmt warnings).

Done! Thank you for the review! 😄

[Thomasdezeeuw]

Thanks @SebastianSchildt @AkhilTThomas!

[AkhilTThomas]

So I think in the short term nothing can be done for CI. The tests do run now (think @AkhilTThomas can confirm, maybe even provide log output), if you run it locally with a toolchain set up.

There is currently no way to set up a toolchain without being a QNX customer. Also likely it is not ok for somebody to "just" set up a private runner for usage in this project based in a single seat dev license (not withstanding the question whether that is an effort/complication you even want to deal with in your CI currently)

So I would hope in the short term we can merge this on a "good faith basis", providing "as is/best effort/no guarantees" support for QNX neutrino.

In the midterm I did see some rumors QNX might become more open (https://www.linkedin.com/posts/alex-oyler_some-big-breaking-news-from-john-wall-activity-7178514730926452736-ZVqR) , so maybe the situation regarding setting up toolchains improves. I am, however, in no way affiliated with Blackberry (the current QNX owners), so I have no ideas what - if any - intentions and timeline are here.

Tests done on qemu x86-64
mio-test-result-x86-64.txt

[Thomasdezeeuw]

Also see follow up pr #1800 to remove the need for any RUSTFLAGS.