alexcrichton
commented
1 week ago At a high level this looks reasonable to me, but one recommendation I might have is that the way we implemented WASIp1 was to have it be a wrapper effectively around WASIp2. Internally all of WASIp1 is implemented in terms of WASIp2's underlying functions. Would it be possible to do that here as well? For example storing a wit::WasiNnCtx inside of a witx::WasiNnCtx directly and then using the Host and such traits to implement the internals?
(not required of course just a suggestion)
Recent discussion in the wasi-nn proposal (see wasi-nn#59, e.g.) has concluded that the right approach for representing wasi-nn "things" (tensors, graph, etc.) is with a component model resource. This sweeping change brings Wasmtime's implementation in line with that decision.
Initially I had structured this PR to remove all of the WITX-based implementation (#8530). But, after consulting in a Zulip thread on what other WASI proposals aim to do, this PR pivoted to support both` the WITX-based and WIT-based ABIs (e.g., preview1 era versus preview2, component model era). What is clear is that the WITX-based specification will remain "frozen in time" while the WIT-based implementation moves forward.
What that means for this PR is a "split world" paradigm. In many places, we have to distinguish between the
witandwitxversions of the same thing. This change isn't the end state yet: it's a big step forward towards bringing Wasmtime back in line with the WIT spec but, despite my best efforts, doesn't fully fix all the TODOs left behind over several years of development. I have, however, taken the liberty to refactor and fix various parts as I came across them (e.g., the ONNX backend). I plan to continue working on this in future PRs to figure out a good error paradigm (the current one is too wordy) and device residence.