WASI: integrate ABI modules into reserved WASM modules #74
Labels
wasi:api
Issues pertaining to the WASI API, not necessarily specific to Wasmtime.
Comments
sunfishcode
added
the
wasi:api
This was referenced Mar 28, 2019
|
WASI Core isn't in the default environment module; it's in the "wasi_unstable" module, which we intend to be temporary. In C header files, this is achieved via the Versioning is an interesting topic that will affect a lot of people in a lot of different ways, so I suggest we defer that discussion until we have a proper forum. |
|
Modularization and versioning are implemented in the WASI repo. |
pchickey
pushed a commit
to pchickey/wasmtime
that referenced
this issue
May 12, 2023
use main module's `cabi_realloc` instead of `memory.grow`
pchickey
pushed a commit
to pchickey/wasmtime
that referenced
this issue
May 16, 2023
use main module's `cabi_realloc` instead of `memory.grow`
abrown
added a commit
to abrown/wasmtime
that referenced
this issue
Aug 8, 2024
This change alters the `wasi-nn` world to split out two different modes of operation: - `inference`: this continues the traditional mechanism for computing with wasi-nn, by passing named `tensor`s to a `context`. Now that `tensor`s are resources, we pass all inputs and return all outputs together, eliminating `get-input` and `set-output` - `prompt`: this new mode expects a `string` prompt which is passed along to a backend LLM. The returned string is not streamed, but could be in the future This change also adds metadata modification of the `graph` via `list-properties`, `get-property` and `set-property`. It is unclear whether these methods should hang off the `context` objects instead (TODO). It is also unclear whether the model of `load`-ing a `graph` and then initializing it into one of the two modes via `inference::init` or `prompt::init` is the best approach; most graphs are one or the other so it does not make sense to open the door to `init` failures. [bytecodealliance#74] (replace `load` with `load-by-name`) is replicated in this commit. [bytecodealliance#75] (return errors as records) and [bytecodealliance#76] (remove the error constructor) is superseded by this commit, since every error is simply returned as a `string` and the `error` resource is removed. [bytecodealliance#74]: WebAssembly/wasi-nn#74 [bytecodealliance#75]: WebAssembly/wasi-nn#75 [bytecodealliance#76]: WebAssembly/wasi-nn#76
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
https://webassembly.github.io/spec/core/syntax/modules.html
WASM already provides the ability to do modules. WASI should tightly integrate with this rather than putting all the APIs in the default environment module. This would also allow us to version the ABIs.
A WASM application could define that it needs the
core1,net2andfilesystem2modules. The runtime can dynamically adapt to that behavior by loading the correct ABIs according to what the application specified. This allows WASI to make ABI changes. It also allows WASI to be deeply modular. It would be very nice to follow semver here.The text was updated successfully, but these errors were encountered: