The goal is to get this is merged into Rust's std library, they wouldn't write std on top of Rustix.
> Wonder if that means it would be easier to verify the correctness of `unsafe` use inside Rust itself?
If you mean usage of unsafe inside std (which the Rust compiler does depend upon), that is one of the explicit goals of Rustix. The usage of unsafe will be much more narrow overall, mostly surrounding the system calls themselves.
The port of libstd linked in the article still uses rustix as a separate crate.
In any case, I hope it remains separate. Third-party no_std code would benefit from it.
I am under the impression that no-std code is primarily the concern of embedded systems that might not have much of an OS [1] at all, nevermind a suite of system calls to Linux.
[1] Like a typical RTOS, that may provide some basic communication primitives, thread creation, and a hardware abstraction layer (HAL).
That is nor necessarily the case. Embedded is a big user, but there are other reasons to use no_std, such as explicitly wanting to avoid heap allocations, or wanting greater control over the native APIs being called.
Also Wasm support (can be viewed as a kind of embedded) and better portability. Anything that helps one separate the platform and more precisely define the platform boundary the better.
Libc is necessary, but not good.
Wonder if that means it would be easier to verify the correctness of `unsafe` use inside Rust itself?