Reimplement wasmtime-wasi on top of wasmtime
#899
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This commit reimplements the `wasmtime-wasi` crate on top of the `wasmtime` API crate, instead of being placed on top of the `wasmtime-*` family of internal crates. The purpose here is to continue to exercise the API as well as avoid usage of internals wherever possible and instead use the safe API as much as possible. The `wasmtime-wasi` crate's API has been updated as part of this PR as well. The general outline of it is now: * Each module snapshot has a `WasiCtxBuilder`, `WasiCtx`, and `Wasi` type. * The `WasiCtx*` types are reexported from `wasi-common`. * The `Wasi` type is synthesized by the `wig` crate's procedural macro * The `Wasi` type exposes one constructor which takes a `Store` and a `WasiCtx`, and produces a `Wasi` * Each `Wasi` struct fields for all the exported functions in that wasi module. They're all public an they all have type `wasmtime::Func` * The `Wasi` type has a `get_export` method to fetch an struct field by name. The intention here is that we can continue to make progress on bytecodealliance#727 by integrating WASI construction into the `Instance::new` experience, but it requires everything to be part of the same system! The main oddity required by the `wasmtime-wasi` crate is that it needs access to the caller's `memory` export, if any. This is currently done with a bit of a hack and is expected to go away once interface types are more fully baked in.
peterhuene
approved these changes
Feb 6, 2020
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This commit reimplements the
wasmtime-wasicrate on top of thewasmtimeAPI crate, instead of being placed on top of thewasmtime-*family of internal crates. The purpose here is to continue to exercise
the API as well as avoid usage of internals wherever possible and
instead use the safe API as much as possible.
The
wasmtime-wasicrate's API has been updated as part of this PR aswell. The general outline of it is now:
WasiCtxBuilder,WasiCtx, andWasitype.
WasiCtx*types are reexported fromwasi-common.Wasitype is synthesized by thewigcrate's procedural macroWasitype exposes one constructor which takes aStoreand aWasiCtx, and produces aWasiWasistruct fields for all the exported functions in that wasimodule. They're all public an they all have type
wasmtime::FuncWasitype has aget_exportmethod to fetch an struct field byname.
The intention here is that we can continue to make progress on #727 by
integrating WASI construction into the
Instance::newexperience, butit requires everything to be part of the same system!
The main oddity required by the
wasmtime-wasicrate is that it needsaccess to the caller's
memoryexport, if any. This is currently donewith a bit of a hack and is expected to go away once interface types are
more fully baked in.