Skip to content

[wasi-common] Polyfill snapshot 0 without copying whole tree #658

@pchickey

Description

@pchickey

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 #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, and subscription 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) host filestat to the old snapshot 0 wasm32 filestat (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

Metadata

Metadata

Assignees

No one assigned

    Labels

    wasi:implIssues pertaining to WASI implementation in Wasmtime

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions