Revert "Merge pull request #166 from sunfishcode/main"

[Stebalien]

Unfortunately, this uses "raw" syscalls by default, which is too much of a breaking change for users that expect to be able to override libc (I only noticed this when writing the changelog, unfortunately).

We'd be able to use rustix if it made "linux-raw" an enabled-by-default feature:

1. Make "linux-raw" a feature, instead of "use-libc".
2. Set default = ["std", "linux_raw"].

Unfortunately, that would be a breaking change.

Alternatively, the standard library would have to switch to rustix by default.

[Stebalien]

So, an alternative is enable the "use-libc" feature by default in this crate:

[features]
default = ["use-libc"]
use-libc = ["rustix/use-libc"]

However, this could potentially cause even more trouble as anyone depending on both this crate and rustix would automatically get opted into libc unless they explicitly disabled it.

[Stebalien]

cc @sunfishcode thoughts? My concern is people using LDPRELOAD and other magic to intercept syscalls.

Although maybe it's not a huge issue? Go makes direct syscalls as well. I'm going to sit on this for a bit (I really do like the idea of removing the dependency on libc where possible).

[sunfishcode]

Using LD_PRELOAD to intercept syscalls is complicated by the fact that glibc's own calls to syscall wrappers often use internal symbols that can't be replaced with LD_PRELOAD, so not all syscalls can be easily intercepted this way.

Other magics to intercept syscalls are ptrace and seccomp, which both do handle raw syscalls.

[joshtriplett]

LD_PRELOAD is an interesting trick, but one known not to work everywhere for this exact reason. I don't think you should force calls to go through libc just to allow for interception via specific symbols, especially when there are more reliable mechanisms to intercept and modify syscalls directly.