Create a trait for custom WASI-ish implementors

[aidanhs]

trafficstars

Motivation

There are two sides to WASI - the consuming side (i.e. the .wasm file) and the implementing side (i.e. the host). Flexibility on the implementing side means you can compile a WASI consumer and then run it on custom implementors.

Implementors today can do this manually themselves, but they end up having to manually redefine the interfaces that the wasmer-wasi crate already has.

Proposed solution

I propose the wasmer-wasi crate defines a trait for the different snapshots of WASI (like https://docs.rs/wasi-common/0.22.0/wasi_common/wasi/wasi_snapshot_preview1/trait.WasiSnapshotPreview1.html) and provides a way for some T implementing that trait to be turned into a WasmerEnv.

This allows implementors to benefit from the types and interfaces already known by the wasmer-wasi crate. The already-existing snapshot{0,1} interfaces would be the 'production quality' implementors of this trait.

Alternatives

1. Do nothing - as today, means that implementors need to define interfaces manually, which is error-prone.
2. Allow specific method overrides on top of the snapshot{0,1} interfaces - means an implementor has no idea about the 'completeness' of their own code or hidden code paths they don't want hitting.

Additional context

• I dug around to see if wasmtime supports this - though it does define the trait I linked above, there appears to be no useful way to use it in the wasmtime-wasi crate to automatically link it into an Instance.
• I noticed a witx file which I believe could be used to (partially) autogenerate this trait - https://github.com/WebAssembly/WASI/blob/8deb71d/phases/snapshot/witx/wasi_snapshot_preview1.witx

[aidanhs]

I see @brain0 has a trait along the lines proposed above at https://wasi.bchlr.de/wasihost_core/wasi_snapshot_preview1/trait.WasiImports.html, including an extensions trait for converting to an importsobject - this seems pretty great.

[Hywan]

Hello,

Are you OK to open a PR to tackle that :-)?

[john-sharratt]

We have recently made progress towards this with a "runtime" trait added in the upcoming wasmer3 release. At the moment it only implements a subset of WASIX but the intent will be to extend this for all of the existing WASI syscalls which need to be unbundled from the memory access code. https://github.com/wasmerio/wasmer/blob/master/lib/wasi/src/runtime.rs

Open to comments and suggestions.