Johnathan Van Why

I would *like* to have `Future` support, but I do not see a way to build it on top of the current `libtock-rs` API. Therefore, I do not have any...

You should be able to determine your toolchain version by running `cargo +stable --version`. The version you currently need is 1.59.0 (the latest stable version). There are two changes we...

> Given that the container I use for Tock already has several Rusts and just crossed 6GiB, marking itself for extermination, I think pinning to a version like in 2....

Off the top of my head, the following two things would get in the way: - Stable rust does not support #![no_std] binaries yet, as some of the lang items...

After https://github.com/tock/libtock-rs/pull/380 is merged and Rust ~~`1.39.0`~~ `1.59.0` is released (which stabilizes `asm!` and `global_asm!`), `libtock-rs` will work on stable Rust. There are a couple things that will still require...

> I think that should be Rust 1.59.0 Good catch, fixed.

In general, it should be possible to use `libtock-rs`' APIs without using dynamic memory allocation. Therefore I'm opposed to the "high level only" approach. Low level APIs can be designed...

Could we address the concerns about `.cargo/config`'s visibility by using symlinks? E.g. we could put the config in `cargo-config` and symlink `.cargo/config` to `cargo-config`. > I would be very upset...

> I think #373 solves this. #373 replaced `DRIVER_ID` with `DRIVER_NUM`, but there's still a mix of `DRIVER_NUM` and `DRIVER_NUMBER`.

It seems reasonable for `elf2tab` to check alignment in non-relocatable binaries, but what about PIC binaries? It seems to me the loader would need to know the alignment requirement.