Stream: git-wasmtime

Topic: wasmtime / Issue #1220 Missing a way to get access to was...

view this post on Zulip Wasmtime GitHub notifications bot (Mar 04 2020 at 10:02):

rene-fonseca commented on Issue #1220:

Yes, wasi_instance_exports would be fine for now.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 11 2020 at 17:23):

fitzgen labeled Issue #1220 (assigned to peterhuene):

For the new wasi.h we can create own wasi_instance_t* wasi_instance_new. But there is no away to access the wasm API using the wasi_instance_t handle. E.g. for getting the export table with wasm_instance_exports.

Seems like we need an API to get the wasi_instance_t from the wasi_instance_t. To avoid having to replicate all wasm APIs as wasi APIs.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 11 2020 at 17:23):

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

Subscribe to Label Action

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

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

</details>

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

Learn more.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 21 2020 at 00:07):

peterhuene commented on Issue #1220:

As I mentioned in #1221, the problem with adding a wasi_instance_exports is that wasm_extern_t won't give any names, so you'd only get a set of functions and their types, without knowing which function is which.

If we were to properly model this, we would need to represent a WASI module with wasm_module_t so you could call wasm_module_exports to get the symbolic information.

So maybe have wasm_module_t* wasi_module_new(wasm_store_t*, const char* name) where name must be a supported WASI version. From there the usual functions would work.

This is a bunch of work, but it would unify the two APIs (Wasm C API and the WASI extensions) more.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 21 2020 at 00:07):

peterhuene edited a comment on Issue #1220:

As I mentioned in #1221, the problem with adding a wasi_instance_exports is that wasm_extern_t won't give any names, so you'd only get a set of functions and their types, without knowing which function is which.

If we were to properly model this, we would need to represent a WASI module with wasm_module_t so you could call wasm_module_exports to get the symbolic information.

So maybe have wasm_module_t* wasi_module_new(wasm_store_t*, const char* name) where name must be a supported WASI version. From there the wasm_instance_* functions would work.

This is a bunch of work, but it would unify the two APIs (Wasm C API and the WASI extensions) more.

view this post on Zulip Wasmtime GitHub notifications bot (May 16 2020 at 12:46):

plicease commented on Issue #1220:

So maybe have wasm_module_t* wasi_module_new(wasm_store_t*, const char* name) where name must be a supported WASI version. From there the wasm_instance_* functions would work.

It would be great from my perspective to be able to treat wasi as regular module and not have to special case it.

Last updated: Dec 23 2024 at 13:07 UTC