Replace linux_rustix opt-in backend with linux_raw
#572
Conversation
There was a problem hiding this comment.
Personally, I think this seems like a lot of added complexity for a backend that is not enabled by default. I think that we should try to find some other way to solve the issues raised in #433, or just not have a rustix/raw-syscall backend right now.
Getting raw syscalls correct can be very complex if we want to support a range of targets, and I don't think we are well situated to maintain such things.
Yes, it's a reasonable option. We can delay this backend until a later release. But I believe we should eventually have a "raw Linux syscall" backend as it was requested several times (#401, #424).
I do not agree with the "very complex" assessment. As mentioned in the comments, I've mostly copied the battle-tested code from Ideally, I would prefer to have the syscall stuff in a separate lean crate, but, unfortunately, |
As suggested [here](#572 (review)) it may be worth to remove `linux_rustix` from the v0.3.0 release. We probably will either return it in v0.3.1, or will introduce a different `linux_raw` opt-in backend (see #572).
This PR replaces the
linux_rustixopt-in backend introduced in #520 withlinux_rawopt-in backend based raw syscalls implemented usingasm!. It noticeably reduces dependency footprint of the crate (see concerns raised in #433). Unfortunately, it means that we have to implement the raw syscalls ourselves.This PR implements
linux_rawsupport only for target arches with stableasm!. Nightly-only support for other targets can be added in later PRs.