no_std tech demo for removing std::io and some std aliases to core/alloc #2137

stevefan1999-personal · 2024-09-28T15:13:26Z

This PR serves as a no_std tech demo for removing the std::io requirement. As a result, many cfg(feature = "std") attributes, mostly related to std::io inclusion, can be removed. This allows the code that assumed buffered I/O to be compiled in a no_std environment, as an alternative to unbuffered I/O API if available.

This is just an initial evaluation, and incorporated some code from no_std_io before as a replacement for the standard I/O functionality. However, other alternatives such as embedded-io exist and could potentially be explored in the future. The choice of no_std_io before for this demo was made based on its simplicity and ease of integration, but we're open to considering other options as we further develop this feature.

Right now, this has been further simplified and the no_std_io requirement has been eliminated, as I re-introduced a bare minimum of no_std_io code that is needed for rustls. However, it uses Box<dyn core::error::Error> to keep custom error, and may also need to change as discussion goes on.

It's important to note that this change doesn't affect the existing functionality for environments where std is available. While most of the unit tests should theoretically be compatible without std, but they still needed std at the moment for extra platform-specific stuff such as Mutex and Filesystem access.

My own private test under std shows that it works, but it needs a converter shim to convert types that implements std::io::Read and std::io::Write to rustls::compat::io::Read and rustls::compat::io::Write:

pub struct Converter<R>(R);

impl<R: std::io::Read> rustls::compat::io::Read for Converter<R> {
    fn read(&mut self, buf: &mut [u8]) -> rustls::compat::io::Result<usize> {
        self.0.read(buf)
    }
}

impl<R: std::io::Write> rustls::compat::io::Write for Converter<R> {
    fn write(&mut self, buf: &[u8]) -> rustls::compat::io::Result<usize> {
        self.0.write(buf)
    }

    fn flush(&mut self) -> rustls::compat::io::Result<()> {
        self.0.flush()
    }
}

codecov · 2024-09-28T15:28:49Z

Codecov Report

Attention: Patch coverage is 81.25000% with 3 lines in your changes missing coverage. Please review.

Project coverage is 94.63%. Comparing base (e52853a) to head (7a4865d).

Files with missing lines	Patch %	Lines
rustls/src/conn.rs	80.00%	3 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2137      +/-   ##
==========================================
- Coverage   94.64%   94.63%   -0.01%     
==========================================
  Files         102      102              
  Lines       23416    23430      +14     
==========================================
+ Hits        22161    22172      +11     
- Misses       1255     1258       +3

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

rustls/src/vecbuf.rs

…d types

djc · 2024-09-29T18:52:07Z

So what is the use case for this exactly? Why not use the unbuffered API, which should not depend on io?

stevefan1999-personal · 2024-09-30T02:39:53Z

8000

So what is the use case for this exactly? Why not use the unbuffered API, which should not depend on io?

Well, it is kinda niche I know, but I'm using it with smoltcp under a custom kernel written in Rust. So while I have to run under no_std, I do have ample amount of memory so that buffered APIs are affordable. What is still not affordable is a large kernel size, though, and surprisingly the unbuffered API actually enlarged the kernel binary size compared to buffered API.

djc · 2024-10-01T07:31:26Z

Well, it is kinda niche I know, but I'm using it with smoltcp under a custom kernel written in Rust. So while I have to run under no_std, I do have ample amount of memory so that buffered APIs are affordable. What is still not affordable is a large kernel size, though, and surprisingly the unbuffered API actually enlarged the kernel binary size compared to buffered API.

I think it would be interesting to dig into that more.

stevefan1999-personal · 2024-10-01T08:30:13Z

Well, it is kinda niche I know, but I'm using it with smoltcp under a custom kernel written in Rust. So while I have to run under no_std, I do have ample amount of memory so that buffered APIs are affordable. What is still not affordable is a large kernel size, though, and surprisingly the unbuffered API actually enlarged the kernel binary size compared to buffered API.

I think it would be interesting to dig into that more.

Alas, this is just a tech demo showing the possibility of how much work we needed to do to enable the no_std with buffered API, but until rust-lang/rfcs#2262 is moving forward, I would still suggest the following few things: Make our own std::io::Error equivalent, make a minimal shim for Read/Write and isolate more real platform dependent stuff

…rsonal/rustls into no-std-tech-demo

djc · 2024-10-01T09:24:05Z

I think it would be interesting to dig into that more.

Alas, this is just a tech demo showing the possibility of how much work we needed to do to enable the no_std with buffered API, but until rust-lang/rfcs#2262 is moving forward, I would still suggest the following few things: Make our own std::io::Error equivalent, make a minimal shim for Read/Write and isolate more real platform dependent stuff

Why is a PR to the rustls project the right shape for "just a tech demo"?

stevefan1999-personal · 2024-10-01T10:39:27Z

I think it would be interesting to dig into that more.

Alas, this is just a tech demo showing the possibility of how much work we needed to do to enable the no_std with buffered API, but until rust-lang/rfcs#2262 is moving forward, I would still suggest the following few things: Make our own std::io::Error equivalent, make a minimal shim for Read/Write and isolate more real platform dependent stuff

Why is a PR to the rustls project the right shape for "just a tech demo"?

Of course, for discussion and figure out better ways to improve it.

Instead of just talking it out as an issue or in the discussion tab (which wasn't enabled), I think setting up the example first would worth much more.

…ech-demo

brody4hire · 2025-01-21T19:27:12Z

I made portable-io crate with a similar idea to compat::io & tried it with these changes, I can raise a PR to propose this if there is any interest.

I may be able to make a fork with this kind of support if it is not wanted here.

I really like this idea, wonder how much interest there is from the user community.

cpu · 2025-02-10T14:03:12Z

Why is a PR to the rustls project the right shape for "just a tech demo"?

Of course, for discussion and figure out better ways to improve it.

I'm not sure this approach is leading to good results. It's been open for some months now and there hasn't been any significant discussion.

I would be more inclined to review the current implementation for providing feedback if the commit history were cleaned up and it was passing CI. However, in general for a task that touches a lot of Rustls I'm a little bit skeptical it's the right idea to dive into a specific solution without first articulating the problem clearly and weighing the available options. IME having maintainer buy-in on the problem & solution will make getting an implementation across the line easier.

stevefan1999-personal · 2025-02-11T08:04:09Z

Why is a PR to the rustls project the right shape for "just a tech demo"?

Of course, for discussion and figure out better ways to improve it.

I'm not sure this approach is leading to good results. It's been open for some months now and there hasn't been any significant discussion.

I would be more inclined to review the current implementation for providing feedback if the commit history were cleaned up and it was passing CI. However, in general for a task that touches a lot of Rustls I'm a little bit skeptical it's the right idea to dive into a specific solution without first articulating the problem clearly and weighing the available options. IME having maintainer buy-in on the problem & solution will make getting an implementation across the line easier.

Hmm, should I squash them together, or just like you also questioned, maybe get a new approach? I thought this would be the least invasive way to do it since it mostly mapped with the collection semantics in std...

For example, std::vec::Vec is actually an alias to alloc::vec::Vec which is obviously no_std, so we reduced an unnecessary std requirement into no_std equivalent without loss of generality, and I also did (mostly?) the same for std::collections::HashMap/hashbrown, but then you need an external requirement which complicates the cargo feature matrix. I'm not sure if I did that or it was already there.

What would be your suggestion to have a more balanced way?

brody4hire · 2025-03-09T19:43:23Z

@stevefan1999-personal I noticed that some recent PRs have been proposed & merged with multiple commits. I think it would really help if you could rebase & organize this into a cleaner & more limited number of commits.

I suspect this should be a new feature for no-std, in a similar fashion to how hashbrown is supported for no-std.

I think it would be ideal if we could find a way to reduce the amount of code vendored from std::io, especially from std::io::Error. I can think of a couple of ideas:

https://github.com/wcampbell0x2a/no-std-io2 seems to be most recent & best supported, but is missing IoSlice as I reported in: IoSlice wcampbell0x2a/no-std-io2#17
I have made portable-io crate, DOES include IoSlice, and I have tried this PR together with my portable-io crate in my own work area.

@stevefan1999-personal / @rustls team I really hope to see this finished and not abandoned or closed out. I think this could prove itself to be really nice for no-std.

stevefan1999-personal · 2025-03-10T02:03:18Z

@stevefan1999-personal I noticed that some recent PRs have been proposed & merged with multiple commits. I think it would really help if you could rebase & organize this into a cleaner & more limited number of commits.

I suspect this should be a new feature for no-std, in a similar fashion to how hashbrown is supported for no-std.

I think it would be ideal if we could find a way to reduce the amount of code vendored from std::io, especially from std::io::Error. I can think of a couple of ideas:

https://github.com/wcampbell0x2a/no-std-io2 seems to be most recent & best supported, but is missing IoSlice as I reported in: IoSlice wcampbell0x2a/no-std-io2#17

I have made portable-io crate, DOES include IoSlice, and I have tried this PR together with my portable-io crate in my own work area.

@stevefan1999-personal / @rustls team I really hope to see this finished and not abandoned or closed out. I think this could prove itself to be really nice for no-std.

I would love to see the continuation of it, but right now my priorities are my company job, and I also got a paper to do. I will try to spend some time on reviving this, but I won't put in much attention and focus into it yet.

After all, this PR serves as a selling point convincing rustls team to adopt no-std for buffered API, but it turns out they still aren't interested in it due to the underlying philosophical problem against the use of external crates for standard library, even if it is proven to be very useful in practice.

Anyway, right now, it is an impasse with its implied silent treatment from the rustls team. I guess we will have to wait for the Rust standard library team to settle on the core::io and the error issue around it in order to make a move. In that case we can push to the extreme by pressuring std team linking this PR as related issue. I can do this if you want me to.

stevefan1999-personal added 4 commits September 26, 2024 00:19

add DerefMut to common state for UnbufferedConnectionCommon

0f95768

run rustfmt

dced9b6

Merge branch 'main' of https://github.com/rustls/rustls

46ad596

no_std tech demo for removing std::io

21da90a

paolobarbolini reviewed Sep 28, 2024

View reviewed changes

rustls/src/vecbuf.rs Outdated Show resolved Hide resolved

stevefan1999-personal added 6 commits September 28, 2024 23:51

use write_all instead of just write for write_to

bfa707c

add more description for the fallback implementation of write_to

ba3b077

run rustfmt

7bf9cc9

add a drop for complete_io when an error happens under no_std context

e68a28d

further constraint the io compat crate to contain only the used types

cf38aca

fixup! further constraint the io compat crate to contain only the use…

045c4ec

…d types

Merge branch 'main' into no-std-tech-demo

a954e7c

stevefan1999-personal added 3 commits October 1, 2024 17:22

remove no_std_io but use our own

faec943

fix misc code like tests and benches

c6de197

Merge branch 'no-std-tech-demo' of https://github.com/stevefan1999-pe…

fdbd3e0

…rsonal/rustls into no-std-tech-demo

stevefan1999-personal added 3 commits October 1, 2024 17:30

fix more tests

7a4865d

replace std with no_std equivalent as much as possible

4840e48

add back the missing std feature

e8623dc

stevefan1999-personal changed the title ~~no_std tech demo for removing std::io~~ no_std tech demo for removing std::io and some std aliases to core/alloc Oct 1, 2024

stevefan1999-personal added 3 commits October 1, 2024 19:16

fixup! add back the missing std feature

d6a176f

fix compression for no_std

c3df849

Merge branch 'main' into no-std-tech-demo

9e5b9e3

brody4hire mentioned this pull request Nov 6, 2024

Rust portable-* crate placeholders brody4hire/ask-me-anything#41

Open

stevefan1999-personal added 2 commits December 8, 2024 02:02

Merge branch 'main' of https://github.com/rustls/rustls into no-std-t…

718294d

…ech-demo

fix the remaining test stuff

148c844

brody4hire mentioned this pull request Jan 21, 2025

top-level sync::Arc alias to support fork for targets with no atomic ptr #2285

Merged

Merge branch 'main' into no-std-tech-demo

eedafd1

brody4hire mentioned this pull request Mar 9, 2025

IoSlice wcampbell0x2a/no-std-io2#17

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

no_std tech demo for removing std::io and some std aliases to core/alloc #2137

no_std tech demo for removing std::io and some std aliases to core/alloc #2137

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

no_std tech demo for removing std::io and some std aliases to core/alloc #2137

Are you sure you want to change the base?

no_std tech demo for removing std::io and some std aliases to core/alloc #2137

Uh oh!

Conversation

Uh oh!

Uh oh!

Uh oh!

Codecov Report

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!