#![no_std] support

[tomaka]

Very long term and possibly not doable in practice.

[tomaka]

Now that alloc is stable and available, this has become a bit more realistically doable.

However, there are two major issues in the codebase that need to be addresses:

• alloc doesn't provide any HashMap, probably because of the randomness of the SIP hasher. We could replace hashmaps with other data structures, or find a no-std-friendly crate that provides hash maps.
• We use std::io::Error a lot, notably in two places: the muxing system and in the context of AsyncRead/AsyncWrite. I don't really have an opinion on how to solve that.

[tomaka]

alloc doesn't provide any HashMap, probably because of the randomness of the SIP hasher. We could replace hashmaps with other data structures, or find a no-std-friendly crate that provides hash maps.

The primary replacement for this would be the hashbrown crate. It is actually the library that the Rust standard library uses internally. The Rust stdlib can't expose HashMap in alloc because of the SIP hasher, but hashbrown doesn't use randomness.

[olanod]

Any updates and thoughts on this? I think is now possible to have async/await code compile in no_std right?

[tomaka]

It is possible to use async/await, but the AsyncRead and AsyncWrite traits of the futures crate use std::io::Error, which isn't available in no-std contexts, and we make heavy use of these traits.

I don't really know how to solve this.

[olanod]

Oh right, well it'll have to wait since it seems moving std::io::Error to alloc might take a while.

[mriise]

Small update for parties interested

Error trait:

rust-lang/rust#90328
rust-lang/rfcs#3192

no-alloc:

https://docs.rs/heapless/latest/heapless has a lot of alloc replacements of things like Vec and String

The "HashMap" (IndexMap) implementation's default hashing algorithm isn't properly suitable* as a pure replacement without a better one, such as HigwayHash

* https://github.com/servo/rust-fnv

... it is important to profile your program to ensure that you are using small hash keys, and be certain that your program could not be exposed to malicious inputs (including being a networked server).

[thomaseizinger]

I am going to close this as unlikely to be actioned. It is possible to write a libp2p implementation using no_std but very likely, it is much more productive to just create a dedictated no_std fork that only supports a subset of features.