Stream: git-wasmtime

Topic: wasmtime / Issue #1221 Can we add new wasi_instance_bind_...

Wasmtime GitHub notifications bot (Mar 04 2020 at 10:08):

rene-fonseca commented on Issue #1221:

Sounds ok to me.

Wasmtime GitHub notifications bot (Mar 11 2020 at 17:22):

fitzgen labeled Issue #1221 (assigned to peterhuene):

Since the WASI spec is still volatile it makes sense to support any module name to be able to let the caller control which functions to bind.

https://github.com/bytecodealliance/wasmtime/blob/78b32e2527e1d857638f284153c308879828a5cd/crates/c-api/src/wasi.rs#L205-L212

wasi_instance_bind_import currently only accepts "wasi_snapshot_preview1". But for my testing I need "wasi_unstable". If wasmtime at some point only accepts a specific module - we should have a way to tell which modules are accepted by wasmtime wasi implementation. But hopefully all modules will be backwards compatible per API function. If that isn't true, we would maybe need something like glibc version per function.

Alternatively we could have a wasi_instance_bind_import API which ignores the module - and lets it be up to the caller fully. wasi_instance_bind_import would still check function type and name.

Wasmtime GitHub notifications bot (Mar 11 2020 at 17:22):

github-actions[bot] commented on Issue #1221:

Subscribe to Label Action

This issue or pull request has been labeled "wasmtime:c-api".

<details> <summary>Users Subscribed to "wasmtime:c-api"</summary>

• @peterhuene

</details>

To subscribe or unsubscribe from this label, edit the <code>.github/subscribe-to-label.json</code> configuration file.

Learn more.

Wasmtime GitHub notifications bot (Mar 20 2020 at 21:54):

peterhuene commented on Issue #1221:

So the problem with representing a WASI instance as a wasm_instance_t is that wasm_instance_exports will return a 1:1 mapping between the underlying wasm_module_t's exports and the module's exports are what describe the symbolic name. Thus the instance's exports don't provide any symbolic name information because normally you would know which instance extern goes to which module export based on array index.

With a WASI instance, there is no wasm_module_t representation, so there's no way to describe what wasm_instance_exports would be returning (i.e. "what is the name of the function?").

So I think we'll still need wasi_instance_t, but I think creating the instance should take the name of the WASI module to support different versions.

Wasmtime GitHub notifications bot (Mar 20 2020 at 23:59):

peterhuene commented on Issue #1221:

I decided to fix this by transparently supporting wasi_unstable from the current API. I've submitted PR #1376 which should hopefully work for you.

Wasmtime GitHub notifications bot (Mar 26 2020 at 19:35):

peterhuene closed Issue #1221 (assigned to peterhuene):

Since the WASI spec is still volatile it makes sense to support any module name to be able to let the caller control which functions to bind.

https://github.com/bytecodealliance/wasmtime/blob/78b32e2527e1d857638f284153c308879828a5cd/crates/c-api/src/wasi.rs#L205-L212

wasi_instance_bind_import currently only accepts "wasi_snapshot_preview1". But for my testing I need "wasi_unstable". If wasmtime at some point only accepts a specific module - we should have a way to tell which modules are accepted by wasmtime wasi implementation. But hopefully all modules will be backwards compatible per API function. If that isn't true, we would maybe need something like glibc version per function.

Alternatively we could have a wasi_instance_bind_import API which ignores the module - and lets it be up to the caller fully. wasi_instance_bind_import would still check function type and name.

Wasmtime GitHub notifications bot (Mar 26 2020 at 19:40):

peterhuene commented on Issue #1221:

So wasi_instance_new now takes a parameter for requesting a supported WASI module name and will return a trap if the module isn't supported. Currently Wasmtime supports wasm_unstable and wasi_snapshot_preview1 for WASI module names.

The .NET API has also been radically changed to make it easier to instantiate modules in a customized host environment.

Now you can configure a host to offer both versions of WASI to its modules, if desired:

var host = new Wasmtime.Host();

host.DefineWasi("wasi_unstable");
host.DefineWasi("wasi_snapshot_preview1");

host.DefineFunction("", "example", () => Console.WriteLine("hello world"));

var module = host.LoadModule("example.wasm");

dynamic instance = host.Instantiate(module);

instance.run();

Last updated: Nov 22 2024 at 16:03 UTC