Added support for vita target

[nikarh]

With these changes mio compiles and (mostly) works with armv7-sony-vita-newlibeabihf target with --cfg mio_unsupported_force_poll_poll --cfg mio_unsupported_force_waker_pipe rust flags.

armv7-sony-vita-newlibeabihf is a Tier 3 target with working std via newlib.

The target has no epoll or kqueue, only poll and select and async pipes, so cfg flags are required for compilation.
This is not an issue for devs using the target, since most if not all who work with it use cargo-vita tool for building, and it automatically adds these flags to RUSTFLAGS.

• Like espidf it has no process API and thus no CLOEXEC
• sockaddr_in is mildly different on this target, and has an additional field
• no ioctl, so set_nonblocking for vita follows illumos
• async pipes are implemented with pipe2 call for this target

[Thomasdezeeuw]

Hello again :)

With these changes mio compiles and (mostly) works with armv7-sony-vita-newlibeabihf target with --cfg mio_unsupported_force_poll_poll --cfg mio_unsupported_force_waker_pipe rust flags.

armv7-sony-vita-newlibeabihf is a Tier 3 target with working std via newlib.

The target has no epoll or kqueue, only poll and select and async pipes, so cfg flags are required for compilation. This is not an issue for devs using the target, since most if not all who work with it use cargo-vita tool for building, and it automatically adds these flags to RUSTFLAGS.

To be clear --cfg mio_unsupported_force_poll_poll/mio_unsupported_force_waker_pipe is not meant to be used for normal development. It's only to overwrite the preferred polling/waking implementation.

Since vita doesn't have epoll or kqueue the preferred polling implementation is the poll(2) one. It's a bit messy at the moment with cfg are round this place (also see #1715), but once merged no develop should have to use a RUSTFLAG to run Mio on vita.

* Like `espidf` it has no process API and thus no `CLOEXEC`

* `sockaddr_in` is mildly different on this target, and has an additional field

* no `ioctl`, so `set_nonblocking` for vita follows illumos

* async pipes are implemented with `pipe2` syscall for this target

👍 LGTM.

Can we add a cargo check to the CI here as well? I think the socket2 one can be copied.

[nikarh]

Hi!

Can we add a cargo check to the CI here as well? I think the socket2 one can be copied.

I can, but it won't compile without these cfg flags right now, and I'm not sure they should be added to ci checks.
Should I change #[cfg()] in code and add vita target so that it compiles without RUSTFLAGS? Or wait for #1715? Or add CI but with the flags?

[Thomasdezeeuw]

I can, but it won't compile without these cfg flags right now, and I'm not sure they should be added to ci checks.

They were actually added to test the poll(2) implementation on the CI, but see below.

Should I change #[cfg()] in code and add vita target so that it compiles without RUSTFLAGS? Or wait for #1715? Or add CI but with the flags?

If you can change them in this pr that would be great. I wanted to this myself in #1715, but I without rustup support for Solaris isn't quite a pain in the but to test.

[nikarh]

Updated PR - added target_os = "vita" to cfg where necessary, and a CI cargo check step.

Although for tokio we still need to set mio_unsupported_force_poll_poll - https://github.com/tokio-rs/tokio/blob/881b510a072f5acd773a10d3be0debf74113404e/tokio/src/io/poll_evented.rs#L171

Maybe this implementation detail can somehow be exposed? (not in the scope of this PR of course)

[Thomasdezeeuw]

Updated PR - added target_os = "vita" to cfg where necessary, and a CI cargo check step.

👍

Although for tokio we still need to set mio_unsupported_force_poll_poll - https://github.com/tokio-rs/tokio/blob/881b510a072f5acd773a10d3be0debf74113404e/tokio/src/io/poll_evented.rs#L171

Maybe this implementation detail can somehow be exposed? (not in the scope of this PR of course)

This is technically Tokio depending on unspecific behaviour (see tokio-rs/tokio#5866 (comment)). Let's try resolve that in tokio-rs/tokio#5866.

[Thomasdezeeuw]

LGTM, can't test, but the CI seems happy.

[Thomasdezeeuw]

Thanks @nikarh

[nikarh]

Hey, sorry to bother you @Thomasdezeeuw, would it be possible to make a release with these changes?
This would help with tokio-rs/tokio/pull/6094

Thanks!