-
Notifications
You must be signed in to change notification settings - Fork 74
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Contributing a migration from rustix to libc #89
Comments
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. |
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? |
I would argue that |
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 |
Because there is no reason in upgrading it.
Which no one migrated to yet. And the actual stable is still 1.48 I worry No one stops you from forking this crate and maintaining it yourself. Maybe in a few years we migrate to |
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 |
Maybe later. |
Duplicate of #92 |
At $dayjob for technical reasons, we've modified this to use
rustix
instead oflibc
. Would you be willing to accept this change as a pull request?The text was updated successfully, but these errors were encountered: