Wasmtime GitHub notifications bot (Feb 02 2024 at 14:04): Wasmtime GitHub notifications bot (Feb 02 2024 at 14:04):alexcrichton added the wasmtime:api label to Issue #7860.
Wasmtime GitHub notifications bot (Feb 02 2024 at 14:04):alexcrichton added the wasm-proposal:component-model label to Issue #7860.
Wasmtime GitHub notifications bot (Feb 02 2024 at 14:04):alexcrichton opened issue #7860:
This was discussed this past week at the BA plumbers summit and the conclusion was that part of the WASI release process will be the expectation that runtimes can update WASI and won't need to carry weighty "old" implementation of prior versions of WASI. For example updating from 0.2.1 to 0.2.0 should mean that only one copy of the 0.2.1 WITs are required and only one host implementation is required. Additionally it was concluded that it should be possible to load a module which imports 0.2.0 into a runtime that has updated to 0.2.1, and additionally it should be possible to be forwards compatible as well. Any APIs defined in 0.2.0 but imported at 0.2.1 should still be possible to run on a runtime that only supports 0.2.0. This means, for example, that guest languages can update to 0.2.1 and so long as no new functionality is used from 0.2.1 they'll still run on all 0.2.0 runtimes.
I believe the best way to implement this in Wasmtime will be more fancy logic in the
wasmtime::component::Linkertype. More-or-less this would involve updating the string used to register imports to chop off the semver-compatible parts. For examplefoo:bar/baz@0.2.0would be inserted asfoo:bar/baz@0.2. Additionallyfoo:bar/baz@1.2.0would becomefoo:bar/baz@1. That lookup string should be enough for both forwards and backwards compatibility. We'll still be able to rely on normal type-checking as well so this in theory shouldn't cause runtime issues.This issue is intended to track this implementation change to
wasmtime::component::Linker.
Wasmtime GitHub notifications bot (Feb 05 2024 at 22:31):Mossaka commented on issue #7860:
Thanks for the write up and makes sense to me! I'd like to highlight the crucial aspects of backward and forward compatibility with the WASI 0.2 release:
- Backward Compatibility: new runtime supporting 0.2.1 APIs should run components targeting 0.2.0 APIs
- Forward Compatibility: old runtime supporting 0.2.0 APIs should run components targeting 0.2.1 APIs
For backward compatibility, it's essential that any modifications to 0.2.1 API signatures or types are implemented in a way that allows the runtime to ignore these changes when executing components targeting 0.2.0.
For forward compatibility, I interpret what you said as as long as the component's using the interfaces / functions / types defined in 0.2.0, they should be able to run on runtimes with 0.2.0 APIs. However, there's no assurance for components targeting newly introduced or altered 0.2.1 APIs.
Is there a plan to introduce a polyfill or similar solution to ensure full forward compatibility when WASI 0.2.1 is released, that is - older runtime can run any components targeting 0.2.1 APIs?
Wasmtime GitHub notifications bot (Feb 24 2024 at 00:12):alexcrichton commented on issue #7860:
Oh dear I apologize @Mossaka I saw your post earlier but only just now saw you had questions at the end:
Is there a plan to introduce a polyfill or similar solution to ensure full forward compatibility when WASI 0.2.1 is released, that is - older runtime can run any components targeting 0.2.1 APIs?
This sort of depends I think. I've posted https://github.com/bytecodealliance/wasmtime/pull/7994 now which is an implementation of this issue and, if merged, will ship with Wasmtime 19. That means that Wasmtime 19, which will probably support WASI 0.2.0, will be able to run WASI 0.2.1 when it's released (so long as you don't use any new features). Wasmtime 17 and 18, however, will not have https://github.com/bytecodealliance/wasmtime/pull/7994 and won't be able to run WASI 0.2.1 since they have strict version matching.
So on one hand the answer to your question is "yes this is supported", but the other hand is "yes but only if Wasmtime 19+ is used".
Given that I wouldn't expect an "official" polyfill to come into existence, but that's not to say there shouldn't be one of course!
Wasmtime GitHub notifications bot (Feb 27 2024 at 20:08):alexcrichton closed issue #7860:
This was discussed this past week at the BA plumbers summit and the conclusion was that part of the WASI release process will be the expectation that runtimes can update WASI and won't need to carry weighty "old" implementation of prior versions of WASI. For example updating from 0.2.1 to 0.2.0 should mean that only one copy of the 0.2.1 WITs are required and only one host implementation is required. Additionally it was concluded that it should be possible to load a module which imports 0.2.0 into a runtime that has updated to 0.2.1, and additionally it should be possible to be forwards compatible as well. Any APIs defined in 0.2.0 but imported at 0.2.1 should still be possible to run on a runtime that only supports 0.2.0. This means, for example, that guest languages can update to 0.2.1 and so long as no new functionality is used from 0.2.1 they'll still run on all 0.2.0 runtimes.
I believe the best way to implement this in Wasmtime will be more fancy logic in the
wasmtime::component::Linkertype. More-or-less this would involve updating the string used to register imports to chop off the semver-compatible parts. For examplefoo:bar/baz@0.2.0would be inserted asfoo:bar/baz@0.2. Additionallyfoo:bar/baz@1.2.0would becomefoo:bar/baz@1. That lookup string should be enough for both forwards and backwards compatibility. We'll still be able to rely on normal type-checking as well so this in theory shouldn't cause runtime issues.This issue is intended to track this implementation change to
wasmtime::component::Linker.
Last updated: Nov 22 2024 at 16:03 UTC