Cypher1 commented on issue #677:
Status update?
yuhr commented on issue #677:
Is this project relevant here?
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?
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.
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?
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
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.
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 thecrates/interface-types
crate for the purpose of this issue can be basically ignored. It doesn't fit into thewasmtime
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 ofwasmparser
but for the interface types binary format.wit-text
- an analogue ofwat
, 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 presentwasm-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 inwasmtime
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 theValType
andVal
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 forwasm_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 thewit_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 thewasmtime
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 likeVal::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 useString
" 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 thewasmtime
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: Nov 22 2024 at 16:03 UTC