Stream: git-wasmtime

Topic: wasmtime / issue #2974 RFC 11: Broken WASM/WASI-C-API emb...

view this post on Zulip Wasmtime GitHub notifications bot (Jun 09 2021 at 12:23):

MartinKolbAtWork opened issue #2974:

We have a scenario that integrates Wasm VMs using the plain standard Wasm-C-Api functionality.
For WASI, the additional WASI specific calls are used.
With the implementation of RFC 11, our code was broken due to two major issues:

The APIs wasi_instance_new and wasi_instance_bind_import are no longer available, and there seems to be no equivalent for these APIs with RFC 11. Is there a guidance on how to rewrite code in absence of these two functions?

What would help for our use-case is something similar to Wasmer’s wasi_get_imports:
https://wasmerio.github.io/wasmer/crates/wasmer_c_api/wasm_c_api/wasi/fn.wasi_get_imports.html

To ask in a more abstract way: Is there a guidance on how to use Wasmtime-WASI-API in conjunction with the standardized Wasm-C-Api, without the proprietary Wasmtime API. For instance, using wasm_store_new instead of wasmtime_store_new.

Thanks,
Martin

view this post on Zulip Wasmtime GitHub notifications bot (Jun 09 2021 at 21:09):

alexcrichton commented on issue #2974:

Thanks for the report, and sorry for the breakage!

Unfortunately there is no workaround for the issue that you're describing. Wasmtime's implementation of WASI is only usable through wasmtime.h APIs, not through the wasm.h APIs. This was a deliberate decision from RFC 11.

The wasm.h header doesn't support a number of features that Wasmtime wants to support (even in its C API) such as:

These features are implemented today in Wasmtime and supported via the C API (through wasmtime.h), and we do not want to try to retrofit all of these options onto the existing wasm.h.

Could you describe a bit more about your use case perhaps, though? I'm curious if there's another way that we could help you out!

view this post on Zulip Wasmtime GitHub notifications bot (Jun 10 2021 at 08:06):

MartinKolbAtWork commented on issue #2974:

Thanks for your reply. The code that illustrates our use-case:

void main() {
    wasm_store_t* store = ...;
    wasm_engine_t* engine = ...;
    wasm_module_t* module = ...;

    // load Wasm file ...

    wasi_config_t* wasi_config = ...;
    wasi_instance_t* wasi =
       wasi_instance_new(store, "wasi_snapshot_preview1", wasi_config, ...);

    wasm_extern_vec_t imports;
    wasm_importtype_vec_t module_imports;
    wasm_module_imports(module, &module_imports);
    wasm_extern_vec_new_uninitialized(&imports, module_imports.size);
    for (size_t i = 0; i < module_imports.size; i++) {
        const wasm_extern_t* ext = wasi_instance_bind_import(wasi, module_imports.data[i]);
        imports.data[i] = const_cast<wasm_extern_t*>(ext);
    }

    wasm_instance_t* instance = wasm_instance_new(store, module, &imports, ...);

    // Call function ...
}

The API calls that are no longer available are wasi_instance_new and wasi_instance_bind_import. We intentionally do not use any Wasmtime types to keep our code portable.
Is there any option to rewrite the code with RFC 11, but keeping the standard Wasm types?

Thanks, Martin

view this post on Zulip Wasmtime GitHub notifications bot (Jun 10 2021 at 14:22):

alexcrichton commented on issue #2974:

Oh I was curious as well as to the general purpose of what your embedding was focused on (e.g. the reason for calling wasm) to see if there's something we could help out with that.

Also FWIW it looks like you're using C++, so you might be interested in the C++ bindings for Wasmtime as well -- https://github.com/bytecodealliance/wasmtime-cpp

view this post on Zulip Wasmtime GitHub notifications bot (Jun 26 2021 at 13:35):

MartinKolbAtWork commented on issue #2974:

Hi @alexcrichton ,

Thanks for your answer and thank you for pointing out the C++ bindings of Wasmtime.
In the scenario we are working on, we explicitly aim for the standard WASM-C-API whenever possible, because this allows to write code fragments that can be used with other WASM-C-API based VMs as well.

Unfortunately, due to legal aspects, I currently can’t explain the purpose of the work.

Could you elaborate about the planned future of wasm-c-api in Wasmtime?
Does Wasmtime plan to support future enhancements of wasm-c-api?
Will the strategy remain that once you need a tiny little feature not covered by wasm-c-api then you need to switch completely to Wasmtime API? I’d be in favor of using wasm-c-api for the basics, and use some VM specific APIs only for these use-cases not covered by the standard API.

Best, Martin

P.S.
I assume the answer to my previous question...

“Is there any option to rewrite the code with RFC 11, but keeping the standard Wasm types?”

... is: “No”, is it?

view this post on Zulip Wasmtime GitHub notifications bot (Jun 28 2021 at 14:19):

alexcrichton commented on issue #2974:

I am not personally aware really of what the future of the upstream wasm-c-api repository is. It hasn't seen much activity in quite some time now. Regardless, though, Wasmtime intends to help evolve that proposal and contribute to it, but at this time we are also not in charge of shepherding it so we can only try to affect its evolution when it gets some more activity.

It is the intention of Wasmtime to continue to implement the upstream C API, however. Unfortunately though due to the lack of activity on the upstream C API there's not a ton of flexibility with the API and it's particularly restrictive for our implementation. Consequently while we support the API with a shim we recommend using Wasmtime's custom API instead since that's where we're maintaining extended functionality like WASI.

If WASI gets an official embedding C API then we would also implement that, but at this time there is no such API.

Sorry, though, to answer your question you're correct in that WASI with Wasmtime's C API today cannot be used exclusively with the wasm.h header file.

Basically the tl;dr; is we want to follow standards, but there's very few standards in this space. For what standard there is it's pretty inactive and relatively incomplete. At this time we implement existing standards but only in a compatibility fashion, and we give the full functionality with our own API otherwise.

view this post on Zulip Wasmtime GitHub notifications bot (Jun 29 2021 at 06:05):

MartinKolbAtWork commented on issue #2974:

Hi @alexcrichton,

thanks for the clarification. That makes sense to me.
I’ll close this issue now.

Best, Martin

view this post on Zulip Wasmtime GitHub notifications bot (Jun 29 2021 at 06:05):

MartinKolbAtWork closed issue #2974:

We have a scenario that integrates Wasm VMs using the plain standard Wasm-C-Api functionality.
For WASI, the additional WASI specific calls are used.
With the implementation of RFC 11, our code was broken due to two major issues:

The APIs wasi_instance_new and wasi_instance_bind_import are no longer available, and there seems to be no equivalent for these APIs with RFC 11. Is there a guidance on how to rewrite code in absence of these two functions?

What would help for our use-case is something similar to Wasmer’s wasi_get_imports:
https://wasmerio.github.io/wasmer/crates/wasmer_c_api/wasm_c_api/wasi/fn.wasi_get_imports.html

To ask in a more abstract way: Is there a guidance on how to use Wasmtime-WASI-API in conjunction with the standardized Wasm-C-Api, without the proprietary Wasmtime API. For instance, using wasm_store_new instead of wasmtime_store_new.

Thanks,
Martin

Last updated: Nov 22 2024 at 16:03 UTC