bytecodealliance / bytecodealliance/wasmtime
WASI support for custom targets
- Dominant language
- Rust
- Stars
- 18.6k
- Forks
- 1.8k
- Avg merge
- 1d 16h
- Merged PRs (30d)
- 135
Description
From the [docs](https://docs.wasmtime.dev/examples-minimal.html#building-wasmtime-for-a-custom-platform)
> Not all features for Wasmtime can be built for custom targets. For example WASI support does not work on custom targets.
This is basically what I need, so I'd like to know(and possibly contribute) what would it take to add WASI support to the no_std version of Wasmtime.
I'm creating a simple "virtual OS" for embedded risc-v and a [custom risc-v based VM](https://github.com/paritytech/polkavm/blob/master/crates/polkavm-linker/riscv32emac-unknown-none-polkavm.json) and would like to run WASI programs on it, the fact that programs need to be pre-compiled ahead of time is actually a plus as it allows distributing the binaries in the VM's format instead of WASM.
An initial MVP would be running a simple WASI component with [`wstd`](https://crates.io/crates/wstd) that reads form stdin and write to stdout and another one that creates a service listening on a socket. The OS abstracts the concept of the filesystem or networking.
Contributor guide
Research direction
Start with the custom-platform Wasmtime documentation and the no_std limitation described there, then review the linked custom RISC-V target and wstd requirements. Clarify the WASI host capabilities needed for stdin, stdout, filesystem abstraction, and sockets, and define the MVP's supported behavior and acceptance tests.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- embedded-iot, operating-systems
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 20/100