Runtime network support for target i686-unknown-linux-musl under linux kernal version 2.6.18

[wizzardx]

Is your feature request related to a problem? Please describe.

When I try to use the "postgres" package under the i686-unknown-linux-musl under linux kernal version 2.6.18, then tokio fails with this error during runtime:

````Err` value: Os { code: 38, kind: Unsupported, message: "Function not implemented" }'```

Describe the solution you'd like

Tokio should, under the i686-unknown-linux-musl compile target, and while running under linux kernel 2.6.18, use some alternative logic which doesn't fail, preventing higher-level libraries and apps from being able to cross-compiled and run on that environment.

Describe alternatives you've considered

I'm considering taking a look at the python synchrononous postgres client libraries on that environment (in that ancient distro), then reverse engineering them into either rust, or another modern programming language development environment (mainly C, or Nim, or something else which uses musl and where I need to work on a lower and much more unsafe level than provided by rust and tokio. And Go Lang recently also dropped support for this kernel version), which targets that environment, in such a way that the reverse-engineered code (using the much older kernel io logic, which should still work on modern kernels), is able to run on both the ancient linux environment, and modern linux environments.

...

Alternately I'm thinking of using the RustPython project compiled to the i686-unknown-linux-musl target, and then from there using a "pure python" postgres driver (eg: pg8000).

Alternately, just sticking to the dev tools and runtimes and libraries that come with that ancient distro from 2017 (Debian 4, Etch), and using that as my "lowest common denominator" - any apps that need to support that platform, can only use tech that was around and easily available when that platform was released.

Additional context

In more detail:

I'm using rust-postgres version 0.19.3

I've added "unimplemented!()" calls in various places to help debug and track down a runtime error, so my line numbers aren't exact because of those:

At runtime I get this error:

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 38, kind: Unsupported, message: "Function not implemented" }', /home/david/.cargo/registry/src/jackfan.us.kg-1ecc6299db9ec823/postgres-0.19.3/src/config.rs:342:14

The panic itself seems to originate from this logic:

        let runtime = runtime::Builder::new_current_thread()
            .enable_all()
            .build()
            .unwrap(); // FIXME don't unwrap

But the actual error, which causes the unwrap to panic, seems to be a lot deeper into the system.

From what I can trace, the build() call goes over into this file:

/home/david/.cargo/registry/src/jackfan.us.kg-1ecc6299db9ec823/tokio-1.19.2/src/runtime/builder.rs

over impl Builder, function build

Which in turn goes to build_basic_runtime

Which then goes to here:

/home/david/.cargo/registry/src/jackfan.us.kg-1ecc6299db9ec823/tokio-1.19.2/src/runtime/driver.rs

Over into the Driver::new() function.

Which in turn calls create_io_stack

Which in turn calls:

crate::io::driver::Driver::new()

Which takes me over to here:

/home/david/.cargo/registry/src/jackfan.us.kg-1ecc6299db9ec823/tokio-1.19.2/src/io/driver/mod.rs

Where Driver::new() calls this function:

mio::Poll::new()

Which is over in this file:

/home/david/.cargo/registry/src/jackfan.us.kg-1ecc6299db9ec823/mio-0.8.4/src/poll.rs

Where this is called:

sys::Selector::new()

Which then takes us over to this file:

/home/david/.cargo/registry/src/jackfan.us.kg-1ecc6299db9ec823/mio-0.8.4/src/sys/unix/selector/epoll.rs

Which has this macro call:

syscall!(epoll_create1(flag))

Where syscall! is in this file:

/home/david/.cargo/registry/src/jackfan.us.kg-1ecc6299db9ec823/mio-0.8.4/src/sys/unix/mod.rs

And where it seems this is where the original error being panicked on is created:

````Err` value: Os { code: 38, kind: Unsupported, message: "Function not implemented" }'```

So from that it would seem that the call to C function epoll_create1 (on my target platform, and with that linux kernel version), is returning error code -1,

Which returns the result of this call:

Err(std::io::Error::last_os_error())

Which would appear to be libc error code 38, which seems to translate to "Function not implemented" within the C API.

The C code for musl, epoll_create1, seems to be here:

https://github.com/esmil/musl/blob/master/src/linux/epoll.c

Where epoll_create1 appears to be assembly language, over here:

https://github.com/runtimejs/musl-libc/blob/master/src/internal/i386/syscall.s

[Darksonn]

The minimum supported kernel version by the Rust language itself is 2.6.32. However, for the particular syscall you are looking for, it is also an issue for our Android support, so there is already a PR at tokio-rs/mio#1590 that adds a workaround for this.

Since issues like this belong in mio, I'm going to close this.