Document the boostrapping strategy

[briansmith]

I think documenting the boostrapping strategy will help contributors a lot in understanding how to solve some chicken-and-egg problems.

Is it a requirement that no C code is allowed at all, even now? Or is that just the eventual goal? Is it a requirement that no external assembler (gas or clang-ml) be required? I personally would rather steed depend on an external assembler rather than using (the unstable) asm!.

IMO it makes a lot of sense to bootstrap things by reusing parts of the entry point code from Go and/or Android (which is partially in assembly language) and/or MUSL, and then incrementally go back and replace the legacy C/assembly code with Rust code. In particular, I think it would be OK to temporarily depend on MUSL's pthreads C code in order to boostrap other things, but I'm not sure if this fits in with your strategy.

[japaric]

The, perhaps not too explicit, plan is to be pure Rust from beginning to end (we are already doing this) and to incrementally provide an API that's 1 to 1 equal to std.

The holes in our API will be filled on an "as-needed" basis. Using the method described here, one can already start compiling crates against steed without changes, in the case of rlibs, or with minimal changes to main, in the case of executables. Obviously, most crates won't compile because steed API is not on parity with std but by trying we'll get compile errors that will inform us on what API need to be prioritized.

Is it a requirement that no external assembler

Not a requirement but I would prefer it because it helps with goal of "hassle free cross compilation". (I'm assuming one needs to install a different gas to compile e.g. ARM assembly into an ARM elf object). I'm not opposed to providing a Cargo feature to use gas instead of asm!.

[briansmith]

I'm not opposed to providing a Cargo feature to use gas instead of asm!.

I imagine it would become burdonsome to keep two copies of assembly language code in sync.