Porting Rust's std to use rustix instead of using libc directly for I/O on Unix-family platforms would factor out unsafe code, both for memory safety and I/O safety, and raw error handling, from std's main implementation code, making it easier to maintain. Secondarily, it'd also bring a number of optimizations, such as avoiding the allocation that std does on every system call that takes a string, and making system calls directly and avoiding errno.
cap-std and mustang demonstrate that rustix can do most of the I/O that std does, and the pieces that are missing should be straightforward to add. rustix and libc can coexist, so the work could be done incrementally.
rustix does depend on some things from std, though there's a working no_std branch, so we know the dependencies. The most interesting here are:
-
std::os::raw::*, CStr, Ip*Addr, SocketAddr*, IoSlice* - Rust has avoided moving these into core because they invove OS-specific types, so perhaps we could introduce a new core_ffi library and move these into it? Or, perhaps rustix should define its own versions of these which convert to and from the std versions. rustix doesn't need them to be full-featured, so it should be doable.
-
BorrowedFd, OwnedFd, etc. - Could these also make sense in a core_ffi library? Alternatively, rustix could similarly define its own.
-
CString - Similarly, this could go into a new alloc_ffi library, or rustix could similarly define its own.
Once we have the dependencies sorted out, I imagine the next steps would be to make a temporary fork of std, and port some calls to use rustix, and then make a proposal to the std maintainers and use the fork to show how it simplifies the code and factors out unsafe, as the primary motivators.
For any of this to happen, I'll need help! Both because it's a lot of work, and because if there isn't community interest in helping with this, it's a sign that this doesn't actually make sense to do.
-
Does the above sound reasonable? Is it missing anything major? Is there anything about rustix's design that should be different? What questions should I be asking here that I'm not?
-
Are there people interested and available to implement pieces of this? Many of the pieces should be straightforward, and I'd be happy to mentor people and explain what needs to be done.
Porting Rust's std to use
rustixinstead of using libc directly for I/O on Unix-family platforms would factor outunsafecode, both for memory safety and I/O safety, and raw error handling, from std's main implementation code, making it easier to maintain. Secondarily, it'd also bring a number of optimizations, such as avoiding the allocation that std does on every system call that takes a string, and making system calls directly and avoidingerrno.cap-std and mustang demonstrate that
rustixcan do most of the I/O that std does, and the pieces that are missing should be straightforward to add.rustixand libc can coexist, so the work could be done incrementally.rustixdoes depend on some things from std, though there's a workingno_stdbranch, so we know the dependencies. The most interesting here are:std::os::raw::*,CStr,Ip*Addr,SocketAddr*,IoSlice*- Rust has avoided moving these intocorebecause they invove OS-specific types, so perhaps we could introduce a newcore_ffilibrary and move these into it? Or, perhaps rustix should define its own versions of these which convert to and from thestdversions. rustix doesn't need them to be full-featured, so it should be doable.BorrowedFd,OwnedFd, etc. - Could these also make sense in acore_ffilibrary? Alternatively, rustix could similarly define its own.CString- Similarly, this could go into a newalloc_ffilibrary, or rustix could similarly define its own.Once we have the dependencies sorted out, I imagine the next steps would be to make a temporary fork of std, and port some calls to use rustix, and then make a proposal to the std maintainers and use the fork to show how it simplifies the code and factors out
unsafe, as the primary motivators.For any of this to happen, I'll need help! Both because it's a lot of work, and because if there isn't community interest in helping with this, it's a sign that this doesn't actually make sense to do.
Does the above sound reasonable? Is it missing anything major? Is there anything about
rustix's design that should be different? What questions should I be asking here that I'm not?Are there people interested and available to implement pieces of this? Many of the pieces should be straightforward, and I'd be happy to mentor people and explain what needs to be done.