Port from libc to rustix

[notgull]

rustix is a crate which provides I/O-safe wrappers around raw system calls on Linux and libc on other Unixes. By using it we can use raw syscalls instead of libc calls, which has a number of performance, safety and code size advantages.

I am wiling to write a PR for this; however there are a couple of items of discussions we have to go over first.

• This will bump this crate's MSRV to v1.63. Is this acceptable?
• It will also add a couple of (mostly inconsequential) dependencies. Is this acceptable?

[newpavlov]

I considered it (personally, I like rustix and use it instead of libc in my projects), but there are several issues:

• MSRV 1.63 is a bit too high for us. rustix has a laxer MSRV policy, so we probably would have to wait until MSRV-aware resolver will be adopted widely enough (or until next breaking getrandom release which may have sufficiently high MSRV).
• Some users are quite sensitive to additional dependencies, regardless whether they are "mostly inconsequential" or not.
• rustix::rand::getrandom accepts &mut [u8], while we provide API which works over &mut [MaybeUninit<u8>].

So we probably will not be migrating to rustix at the very least until hypothetical getrandom v0.3.

[notgull]

For your last point, getrandom_uninit is exposed in rustix now.

For the rest, I agree. We’ll have to wait.

[newpavlov]

getrandom_uninit is exposed in rustix now.

Ah, good to know!

[josephlr]

@notgull is it the intent of rustix to support all target_family = unix Rust targets? We try to support every rust target, and I would be a pain to deal with both rustix and libc crates.

We could maybe switch just the use_file.rs code to use rustix, which would require Linux, Android, Haiku, Redox, NTO and AIX support.

[newpavlov]

I think it makes sense to use rustix only on Linux and Android for the raw syscall feature. For other targets it's essentially a glorified libc wrapper. We probably can limit its use only to the getrandom path and make it a (disabled by default) crate feature.

[notgull]

@notgull is it the intent of rustix to support all target_family = unix Rust targets? We try to support every rust target, and I would be a pain to deal with both rustix and libc crates.

rustix supports all of the Unix targets, as well as some of the other targets, like Windows (through winsock).

We could maybe switch just the use_file.rs code to use rustix, which would require Linux, Android, Haiku, Redox, NTO and AIX support.

Yes, I think this would work.

I think it makes sense to use rustix only on Linux and Android for the raw syscall feature. For other targets it's essentially a glorified libc wrapper. We probably can limit its use only to the getrandom path and make it a (disabled by default) crate feature.

This sounds like a pain to manage, especially when rustix is present enough in the ecosystem that you're probably going to import it anyways.

[newpavlov]

This sounds like a pain to manage, especially when rustix is present enough in the ecosystem that you're probably going to import it anyways.

We are unlikely to use rustix by default and, as noted above, I don't see reasons to use it on non-Linux platforms in our case. So rustix-based code is likely to be behind a feature flag. Enabling the hypothetical linux-raw feature will be no more painful than enabling optional rustix dependency.