DRAFT RFC: limited no-std I/O support using portable-io

[brody4hire]

Motivation

I have been very interested in getting some more widely-used Rust libraries working with no-std for embedded devices.

no-std support was requested in #3544 /cc @surechen

My initial idea is to start achieving this kind of support with help from portable-io crate that I recently published.

NOTE that my primary intention is to start discussion on supporting no-std, with a working demo, and would be very happy to discuss any possible alternative solutions.

Possible alternative solutions

• split the core I/O out to another crate, say tokio-io, maybe like it was done in the past, and only support no-std in that crate
• keep these no-std I/O updates in a separate fork
• move the optional Tokio features into one or more separate Tokio packages to keep the core Tokio more simplified & focused
• Update Tokio to vendor some of the std::io traits & classes, working with no-std
• It would be ideal if they could move most or all of the Rust std::io functionality into core, as discussed in RFC: Proposed refactoring to implement core::io rust-lang/rfcs#2262

Solution

Proposed solution

This is a proposal to get the core IO & optional io-util features working with no-std using some of the Rust I/O traits & types that I extracted in portable-io crate.

Features added:

• std - proposed to be enabled by default
• portable-io - option to use portable-io instead of std::io for the standard I/O traits & types

with some feature requirements & restrictions:

• at least one of std or portable-io features must be enabled (both can be enabled)
• cannot use portable-io with fs, net, process, rt or signal features

other implementation notes:

• using Mutex from parking_lot with slight API variation to support no-std in tokio/src/io/split.rs - I think it would be ideal to use a more portable mutex API
• I made a quick adaptation in tokio/src/io/util/write_all_buf.rs to simplify logic as needed for portable-io option - I think this logic should be simplified in a separate PR for normal std::io usage as well

Major drawbacks:

• feature configuration slightly more complex
• use of no-std directive requires updates throughout the Tokio codebase to explicitly import std crate features that would otherwise have been implicit, adding some complexity to the existing imports
• portable-io crate is new & unproven - it is yet another alternative for Proposed refactoring to implement core::io rust-lang/rfcs#2262 (looks like some other alternatives had stopped development)

---

Testing done:

• cargo test -F full -p tokio ✅

Build testing done:

• cargo build --no-default-features -F portable-io -p tokio
• cargo build -F portable-io -p tokio
• cargo build --no-default-features -F portable-io,io-util -p tokio
• cargo build -F portable-io,io-util -p tokio
• cargo build --no-default-features -F portable-io,io-util,macros,time -p tokio
• cargo build -F full -p tokio # (same as before; includes std; DOES NOT include portable-io)

---

Deferred for now:

• no-std support for runtime tasks - I would like to see this, would likely require major rework of context state maintained in thread_local!
• use portable-atomic to enable building for targets with no atomic ptr (etc.)
• update tokio-stream & tokio-util to support no-std (I have started this in my workarea)

---

Loose ends & major TODO items:

• update documentation
• check & resolve any CI build issues
• update build testing in CI
• update CI testing to try building for embedded no-std target (with no std library available)
• fs test mock not working with these updates - seems to be an issue between these updates & mockall in tokio/src/fs/mocks.rs - testing with fs disabled for now - needs further investigation
• cargo test with portable-io feature
• resolve lint & clippy issues
• resolve or defer any other XXX todo items in these updates

[Darksonn]

My initial reaction is that this is not going to happen. Other runtimes can support the no-std use-case.