Contributing a migration from rustix to libc
Closed this issue · 9 comments
At $dayjob for technical reasons, we've modified this to use rustix instead of libc. Would you be willing to accept this change as a pull request?
for technical reasons
Please openly and directly state those reasons. (Which is a requirement for any change to be merged.)
We have an internal requirement to make syscalls instead of using libc, Rustix is our preferred way of achieving this.
We figure that up streaming this would help improve crate safety (removing unsafe libc calls), it also helps reduce our maintenance burden. memfd-rs have done a similar thing lucab/memfd-rs#27 previously.
We have an internal requirement to make syscalls instead of using libc, Rustix is our preferred way of achieving this.
This does not really make the reasoning much clearer. Why do you have this requirement? What is achieved by making system calls directly instead of going through libc?
rustix requires Rust 1.63, while this crate requires 1.36
it also helps reduce our maintenance burden
I would argue that libc has less maintenance since this is the official way to interact with an OS.
Is there any particular reason for the v1.36 MSRV? It's four years old at this point (as of today, wow), and even Debian Stable uses v1.63 as of the latest release.
I would agree that rustix would be preferred at this point in time. I've been working to migrate some of the GUI crates in the Rust ecosystem to rustix, and we've seen noticeable performance improvements and lower instruction counts.
Is there any particular reason for the v1.36 MSRV?
Because there is no reason in upgrading it.
Debian Stable
Which no one migrated to yet. And the actual stable is still 1.48
Not like I care much.
I worry rustix would lead to more maintenance burden and I have no time for it.
And I doubt that libc usage can lead to any measurable bottlenecks.
No one stops you from forking this crate and maintaining it yourself. Maybe in a few years we migrate to rustix.
I worry
rustixwould lead to more maintenance burden and I have no time for it.No one stops you from forking this crate and maintaining it yourself. Maybe in a few years we migrate to
rustix.
I'd hate to fork this crate, since it would cause ecosystem fragmentation that I would prefer to avoid. A healthy ecosystem doesn't maintain two parallel versions of the same crates with minor differences.
I would be happy to help maintain this crate, especially the rustix parts as I have experience with rustix. I doubt that there would be much practical difference between this and the current libc implementation.
Maybe later.
Duplicate of #92