Stream: git-wasmtime

Topic: wasmtime / issue #677 Support for Interface Types in wasm...

Wasmtime GitHub notifications bot (May 14 2021 at 06:02):

Cypher1 commented on issue #677:

Status update?

Wasmtime GitHub notifications bot (Nov 28 2021 at 23:35):

yuhr commented on issue #677:

Is this project relevant here?

• https://github.com/bytecodealliance/wai-bindgen

Wasmtime GitHub notifications bot (Jan 28 2022 at 08:38):

tqwewe commented on issue #677:

When running wasmtime in Rust I get an error saying support for interface types has been temorarily removed.

for re-adding support for interface types you can see this issue

I had a scan through the comments here on how to re-add support, but didn't see any solution.
Is there any way of adding support back, or do we just need to wait?

Wasmtime GitHub notifications bot (Jan 28 2022 at 10:34):

tschneidereit commented on issue #677:

Native support for Interface Types will be re-added to Wasmtime together
with support for WebAssembly Components in the not-too-distant future. For
now, wit-bindgen <https://github.com/bytecodealliance/wit-bindgen>
(formerly known as wai-bindgen / witx-bindgen) is the right way to use
Interface Types, though note that the details of the IDL and the bindings
are still changing in breaking ways.

@radu-matei recently published an excellent blog post
<https://radu-matei.com/blog/intro-wasm-components/> describing how
Components work and how to use wit-bindgen and other tools to work with
them.

Wasmtime GitHub notifications bot (Sep 07 2022 at 19:28):

kushaldas commented on issue #677:

Can someone please write some example on how to use wit-bindgen and write a module in Rust and then use it say from Python?

Wasmtime GitHub notifications bot (Sep 08 2022 at 00:43):

coderedart commented on issue #677:

Can someone please write some example on how to use wit-bindgen and write a module in Rust and then use it say from Python?

I dont think you can do that yet because component model implementation is still ongoing https://github.com/bytecodealliance/wasmtime/issues/4185

Wasmtime GitHub notifications bot (Oct 24 2023 at 16:28):

alexcrichton commented on issue #677:

This is quite an old issue at this point and the component model is effectively fully supported in Wasmtime right now, so I'm going to close this.

Wasmtime GitHub notifications bot (Oct 24 2023 at 16:28):

alexcrichton closed issue #677:

I'd like to open this as a sort of meta-issue about supporting WebAssembly Interface Types in the wasmtime crate and API. The current support via the crates/interface-types crate for the purpose of this issue can be basically ignored. It doesn't fit into the wasmtime crate API at all, it's outdated, and it's not how I think we want the API to look long-term.

The Interface Types proposal has settled a bit more on design lately, where the general idea is that there are a set of adapter types which adapter functions can use. The actual interface of a wasm module will be the adapter functions imported/exported, rather than the core wasm imports/exports.

For some more background, I've got a number of Rust projects supporting the current snapshot of the wasm interface types proposal:

• wit-parser - an analogue of wasmparser but for the interface types binary format.
• wit-text - an analogue of wat, but for the interface types text format.
• wit-validator - a crate which performs simple validation of the wasm interface types section of a module, if present
• wasm-bindgen has now been updated to use these crates and emit wasm interface types modules compatible with the current proposal. This support hasn't been published, though, and I'd like to hold off until there's support in wasmtime itself.

I've been thinking today about how best to integrate interface types into the wasmtime set of crates. There's a lot of moving pieces and lot of possibilities for how this can work, but I'd like to make a concrete proposal about how this could be integrated. This is going to be a pretty big change, though, so I'd want to be sure to get buy-in from relevant folks before moving forward.

The general gist of what I'm thinking is:

• The wasmtime crate doesn't actually change a whole lot, but the ValType and Val enumerations are extended with all types from the interface types proposal. This namely means signed/unsigned 8-64 bit integers as well as a string type will show up.
• The exports listed by wasmtime modules/instances change depending on the presence of the wasm interface types section.
  • If not present, then everything is the same as it is today
  • If present, the core module exports are ignored and the only exported items are the items listed in the wasm interface types section.
• The imports taken during instantiation are a bit tricky. Today they're a list of imports which correspond 1-to-1 with the list of imports reported from a module. I think we'll still want this 1-to-1 matching, but the list of imports reported from a module will be modified as follows:
  • If no interface types section is present, everything is the same as it is today.
  • If the interface types section is present, then some of the imports of the core module may be satisfied by the adapter functions. To handle this the list of imports required to instantiate the module will first be the set of core wasm imports, in order, that do not have adapters hooked up to them. Then the adapter imports will be listed.
• The C API would receive similar updates. The wasm_val_t type would have a few new codes for wasm_valkind_t and the union would have a few more items packed inside of it. I haven't thought a huge amount about the ownership of strings and such, but I'm assuming that we can think of something pretty reasonable here.
• As a minor change, the wasmtime executable would use the wit_text crate to parse input files, which would parse any of *.wat, *.wasm, or *.wit files.

After these changes are implemented then the crates/interface-types crate would just be deleted, since it is no longer needed. The Python/Rust extensions would be updated to use the wasmtime crate directly, and would provide all necessary mappings for strings/etc. Additionally the .NET extension could be updated with more support since this would all be present in the C API.

Some questions I've wanted to make sure we've got covered when landing all this are:

How will future interface types changes affect this design?

Given this setup the only public-facing change to the design of interface types will be the set of supported types/values. Otherwise I think everything else can be internal changes (yay!) which we take care of one way or another.

How will adapters get implemented today?

I'm thinking that we'll basically just have an "interpreter" for all adapter instructions. Eventually we can get fancier with more JIT-like support but I'd like to get the bare-bones up and running first.

What about the laziness of types?

One of the ideas in the interface types proposal is that adapter instructions are often lazy to minimize copying data between various locations. This'll all boil down to the Val::String representation I think. For now I'm imagaining something like Val::String holding a memory reference, pointer, and length. That way when requested you can read off the entire string, or if you want you could get raw access and peek at the bytes yourself. I'm not really 100% sure how this will work though, but I'm also assuming that it's ok to "cop out" in the interim and "just use String" to see how far it gets us.

This is something I'm particularly curious to hear feedback on though. Especially as more and more types come into the interface types proposal, this is going to get more and more important. For example it'd be pretty awesome if we could start now defining wasi APIs in terms of interface types, but this is all likely a good ways off so perhaps a bit premature to worry about this.

What about linking modules together?

I'm not even gonna try to approach this in a first pass. The main interesting thing here is that if you link together two wasm modules using wasm interface types you can ideally create a highly-optimized adapter function in the middle of the two. I don't plan to tackle this in our initial support though, and while this should work one way or another, it'll likely be relatively slow and copy/allocation-heavy.

Is wasmtime the right crate to put this in wrt stability?

Interface types and its proposal are pretty unstable, with lots going to change now and in the future. Is it ok to now hook up the interface types proposal into the public API of wasmtime? That will be a continued source of instability for consumers of the API (new type variants basically). I'm hoping that new types don't come along all that often, and I'm also hoping that stability isn't necessarily paramount in the wasmtime crate yet that this is ok.

I don't really have many other alternatives though of how to integrate interface types into the wasmtime project. So if others think that interface types are too unstable to go into the wasmtime crate, now would be a good time to discuss that, as well as possible mitigations :)

Last updated: Dec 23 2024 at 12:05 UTC