Closed jmillikin closed 10 months ago
We discussed this in the libs-api meeting. We have no objections! Feel free to open a tracking issue and open a PR to rust-lang/rust to add it as an unstable feature.
Note that there's another accepted ACP that proposes to add vectored IO support for unitialized buffers: #104 Depending on how that gets implemented that might entail also moving iovec to core. You may want to coordinate with the author.
Thanks! Filed https://github.com/rust-lang/rust/issues/117693 for tracking, and sent PR https://github.com/rust-lang/rust/pull/117694 for review.
Note that there's another accepted ACP that proposes to add vectored IO support for unitialized buffers: #104 Depending on how that gets implemented that might entail also moving iovec to core. You may want to coordinate with the author.
Vectored IO support and IoSlice
/ struct iovec
are both OS-specific, so I think migrating them to core
(even partially) would be infeasible absent some deep magic that could unify IoSlice
and &[u8]
.
I think it was in the context of moving io::Error to core the team decided that it's ok to have target-specific type declarations in core. So iovec would then also have to exist in core if that would be needed directly on BorrowedBuf
. If separate types are needed anyway then it can stay in std.
It was pointed out we already do have OS-specific type declarations in core::ffi
at least.
Proposal
Problem statement
I would like to do I/O in a
no_std
context, and it would be nice if I could use the standard library's existing safe abstractions for reading into an uninitialized buffer.Motivating examples or use cases
First case: compiling to WASM with
no_std
to avoid the large size and incomplete implementation ofstd
forwasm32
. I want to useBorrowedBuf
/BorrowedCursor
as part of the interface between the WASM module and the host.Second case: binaries for the Linux early boot environment (initrd), which has tight size constraints and therefore works best with
no_std
binaries that do I/O via raw syscall. I want to useBorrowedBuf
/BorrowedCursor
in the API that wrapsSYS_read
/SYS_readv
.Solution sketch
Just move the existing implementation from
library/std/src/io/readbuf.rs
intolibrary/core/src/io/
. Maybe give it a different tracking feature likecore_io_borrowed_buf
so it could be stabilized separately fromfeature(read_buf)
.It's not a big diff:
Alternatives
Do nothing?
Links and related work
https://github.com/rust-lang/rust/issues/78485: Tracking Issue for RFC 2930 (feature
read_buf
)What happens now?
This issue contains an API change proposal (or ACP) and is part of the libs-api team feature lifecycle. Once this issue is filed, the libs-api team will review open proposals as capability becomes available. Current response times do not have a clear estimate, but may be up to several months.
Possible responses
The libs team may respond in various different ways. First, the team will consider the problem (this doesn't require any concrete solution or alternatives to have been proposed):
Second, if there's a concrete solution: