pchickey commented on issue #658:
the wiggle/wasi-common work done earlier this year finished this
pchickey closed issue #658:
Presently, wasi-common copies essentially its whole implementation into a subdirectory in order to provide separate implementations for snapshot 1 and snapshot 0. This was done in the name of expedience.
In addition to creating a maintenance burden as the two trees get out-of-sync (see https://github.com/bytecodealliance/wasmtime/pull/647) means that Lucet (and probably other implementations as well) need to use a different WasiCtx type depending on whether the guest code is running snapshot 0 or 1. Rather than add logic to Lucet to support both versions of the WasiCtx struct, I'd like to transform wasi-common to support both snapshots with as much common code as possible. Ideally, the hostcall implementation for snapshot 0 will be a proxy to snapshot 1's, and translate arguments from snapshot 0 types to snapshot 1 types whenever they are incompatible.
The incompatible types between snapshot 0 and 1 are, thankfully, pretty small: just the
filestat
,whence
, andsubscription
types have different representations, but semantically they work more or less the same. So, we should be able to write conversion functions to go back and forth between the canonical (snapshot 1 based) hostfilestat
to the old snapshot 0 wasm32filestat
(and so on).One barrier to proxying
hostcalls_impl
code is that the concerns of deserializing / serializing types from wasm guest to host, and the some of the logic of implementing the interface, are mixed in the same function bodies. I'd to decompose this code so that the snapshot 0 compatibility can be slotted in without duplicating any of that logic.Ideally, once the hostcall impls are decomposed, we could generate all of the deser/ser code from witx. I'm working on functionality in witx to reason about compatibility between interfaces that we could use to automate most of the work to support snapshot 0 in terms of snapshot 1, by just providing the conversion functions for the incompatible types. The work over in the WASI repo is at a stopping point until I see exactly how to use it over here, I think.
This is a fairly significant undertaking that will move some important code around, so I'd like to coordinate these changes with everyone else working on wasi-common. I'll use this issue to track my progress and seek feedback on the overall design, and split this work into a bunch of smaller PRs. cc @kubkon
Last updated: Dec 23 2024 at 12:05 UTC