TL; DR steed

What the title says. Let’s build a new (*) std . Same functionality and same API as the current one but that doesn’t use libc. Instead this new std will directly interface with the Linux kernel via system calls.

(*) Not really “new” because most of the implementation will be the same as the current one.

“Why?” For me, because of:

Dead simple cross compilation. Cross compiling Rust code is very simple. It’s the C code what complicates cross compiling Rust programs today: You need a cross C toolchain and cross compiled C libraries, and have to care about glibc versions on both the host and on the targets.

Better optimization (inlining) due to everything being written in Rust.

It’s a chance to audit, in the form of a rewrite, the C code that every Rust program depends on.

The usual Rust over C advantages: Panics instead of buffer overflows, less UB (which has bitten us before), etc.

I have laid out the foundation in this repository. It already contains:

IMO, the most important thing: Testing. The repo is being tested on these architectures: AArch64, ARM, PowerPC, PowerPC64, x86 and x86_64 on each pull request. The test infra also supports MIPS, MIPS64 and SPARC64 but the tests are not passing so those targets are currently disabled.

A system call interface. Basically a fork of the syscall crate that supports more platforms and that enumerates way more system calls than we’ll ever need.

A pure Rust memory allocator. Courtesy of the redox project.

Standard I/O and File I/O support. Not on parity with std but enough to build simple programs.

Completing this is going to take a lot of work. It’s going to be equivalent to re-implementing chunks of libc, libpthread, libm, etc. in Rust. LoC-wise, however, it’s going to be mostly copy pasting code from std .

And that’s where you come in! There’s plenty to do. The issue tracker contains a list of things to do that have been classified according to (my estimate of) their difficulty. There’s easy stuff that’s only about copy pasting code from std , and there’s less easy stuff that’s mostly about copy pasting code from std plus adding one or two syscalls here and there.

In the short term, I’m going to add some magic to Xargo so we’ll be able to build std programs against this new std to compare / benchmark them. Eventually, when PAL becomes a reality, I’d like to refactor the new std into a pal crate that can be plugged into std .

cc @briansmith