Adding support for QNX OS #6421
Conversation
tokio/src/process/mod.rs
Outdated
| #[cfg(target_os = "nto")] | ||
| self.std.uid(id as i32); | ||
| #[cfg(not(target_os = "nto"))] | ||
| self.std.uid(id); |
There was a problem hiding this comment.
| #[cfg(target_os = "nto")] | |
| self.std.uid(id as i32); | |
| #[cfg(not(target_os = "nto"))] | |
| self.std.uid(id); | |
| #[cfg(target_os = "nto")] | |
| let id = id as i32; | |
| self.std.uid(id); |
|
Thanks for the PR. On the assumption that the mio PR is merged, then I am happy to add it here as well.
No, it will just go in with the next minor release and be available starting from Tokio v1.37 (or later depending on timing). Unlike mio, we don't have multiple supported major versions.
Adding support in CI is preferred but not required. Often,
Tokio has a list of platforms with guaranteed support and a bunch of other platforms we support on a best-effort basis. This will not be something we guarantee ongoing support for, but I do not mind adding it. |
tokio/src/net/unix/ucred.rs
Outdated
| @@ -161,7 +161,7 @@ pub(crate) mod impl_netbsd { | |||
| } | |||
| } | |||
|
|
|||
| #[cfg(any(target_os = "dragonfly", target_os = "freebsd"))] | |||
| #[cfg(any(target_os = "dragonfly", target_os = "freebsd", target_os = "nto"))] | |||
There was a problem hiding this comment.
Looking at my diff for tokio 1.18.2, I had enabled the impl_netbsd path, not the impl_bsd path. I presumably did this as it includes the PID whereas getpeereid() does not. Any argument why the getpeereid() path should be used over this?
There was a problem hiding this comment.
I don't know what is the correct answer for this target.
There was a problem hiding this comment.
You are right, using the impl_netbsd is better. I will update the PR
|
Running test suite would need nix-rust/nix#2055 not a blocker now for "best effort" QNX support, but preferably should be solved |
|
Hi, Nix maintainer here, that Nix PR wasn't merged because we think it might not be worth considering how small the user group is, but if tokio wants this target support and it is blocked by that Nix PR, then I am willing to merge it. |
|
That's needed to compile the test-suite, but would it actually enable us to run the tests? Can we run this OS in CI? |
|
Hi @Darksonn : Yes, it would enable to compile, run tests. Which is good. Running all this in CI seems more complicated, see also my comment on mio tokio-rs/mio#1766 (comment) Again, as QNX users we appreciate everything that moves QNX support a bit closer to be on-par with other Tier 1 targets, but there is still some way to go. How far individual projects are willing to go to support this -for now- niche target is of course up to the communities. First step would be having some "not guaranteed to work/best effort code", that gives some amount of out-of -the-box functionality. Obviously, for all users it would be good to be able to run the test suite at least locally, especially since CI testing might still be a slightly harder nut to crack. |
|
This has been merged for mio. Any updates on the PR for Tokio? |
Hi @Darksonn We are waiting for the merge of the nix fix and one on the signal-hook-registry as well. |
|
Is there a link to the signal-hook-registry change? |
Unfortunately not yet, its stuck with an internal clearance 😢. But its a one liner with a suppression for SA_RESTART being unavailable for nto target. |
That it was, it isn't anymore vorner/signal-hook#158 |
|
Any updates here? I'm okay with merging it before it goes into other dependencies, since the change is so small. (But I do have a pending change request.) |
|
Hi, it is not forgotten. May take a few days before sitting at a suitable computer. Just to be sure, the change you are referring is the shorter/ more "elegant" way of doing the |
|
Okay, that's fine. And yes, that's what I meant. |
This enables tokio to be used on QNX.
It also depends on
tokio-rs/mio#1766
@AkhilTThomas I added you to the fork, so you can write there as well
The changes are rather trivial, the main thing is a i32/u32 type mismatch that is handled
Not so sure what is expected/can done in terms of testing, as I assume there are no QNX machines in CI? What are the expectations here?
Once this is in acceptable form, would we need to backport it on one of the many version branches?
As just tokio users we would appreciate some form of QNX support being available out of the box on released tokio versions, (even if would be hidden behind a "here be dragons, we have no idea what this does" kind-of flag )