bytecodealliance / bytecodealliance/wasmtime

WASI support for custom targets

Open
#10,075 2 comments 0 reactions 0 assignees View on GitHub
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.