Kevin Boos (Jun 15 2022 at 19:45): Kevin Boos (Jun 15 2022 at 19:45):Hi wasmtime gurus! Over the last several months, I have been working on porting wasmtime to a no_std environment atop Theseus OS, and as of a few weeks ago I have an initial working version. For the sake of transparency, this work is part of a project sponsored by Futurewei.
AFAIK, this is the first port of wasmtime to a no_std platform, though technically we did add some std-like features to Theseus to get it to work.
Anyway, the next step is to integrate our implementation of WASI into the wasmtime ecosystem. We have an existing WASI implementation that was written to be plugged into the wasmi interpreter crate (some parts borrowed from Redshirt).
This brings me to my primary question: how do I add support for a new host OS to the wasi-common crate in a way that wasmtime can use it to fulfill dependencies on WASI?
I am quite confused on how everything fits together: crates/wasi, crates/wasi-common, and especially code generation with wiggle. I'm unsure if I have to port all of these crates to no_std, which I'm trying to avoid because it would be another massive effort. Perhaps I can just port wasi and wasi-common and skip wiggle, which seems like a proc_macro sort of thing that isn't an actual runtime dependency of wasmtime?
Thanks in advance!
Kevin Boos (Jun 15 2022 at 19:54):I should also add that I have read this excellent blog post about WASI-nn by Andrew, but am not sure I fully understood everything therein. Naturally, it doesn't mention anything about no_std.
Dan Gohman (Jun 15 2022 at 23:36):wiggle is the bindings generator that wasmtime's WASI implementation uses to generate bindings from witx API descriptions. It takes care of a lot of the boilerplate of building a WASI implementation. But, if you have your own WASI implementation already, you may not need it. You may be able to just use the embedding API to expose the WASI functions to wasm.
Dan Gohman (Jun 15 2022 at 23:37):Also, for context, there is a major push happening right now to build up wit-bindgen to the point where it can be the new way that we implemen WASI APIs in Wasmtime, replacing the current witx system.
Kevin Boos (Jun 16 2022 at 00:24):Thanks @Dan Gohman for the reply! I did indeed consider using the embedding API's Linker to add our WASI implementation as custom host state. That's a good first step to take, but I would ideally like to be able to use the default wasmtime_wasi functionality like add_to_linker() and the WasiCtx types, as is possible with other existing host OSes.
[wiggle] takes care of a lot of the boilerplate of building a WASI implementation
That's great to hear. However, where does the actual implementation come from, e.g., for a host target like x86_64-unknown-linux?
Perhaps I'm misunderstanding things, but there must be a platform-specific implementation of the WASI syscall trait(s) generated from the witx spec (?). I presume the same set ofwiggle-generated WASI bindings is generated for the major tier 1 platforms, and then implemented in a unix- or windows-specific manner.
Our WASI implementation likely needs to be redesigned, so I'm totally fine with making major changes to support the existing wasmtime infrastructure surrounding WASI.
Dan Gohman (Jun 16 2022 at 00:26):If you look at crates/wasi-common/src/snapshots/preview_1.rs, you'll see a wiggle::from_witx! invocation which parses a witx file and generates a trait, and a little further down, impl wasi_snapshot_preview1::WasiSnapshotPreview1 for WasiCtx
Dan Gohman (Jun 16 2022 at 00:28):That said we're working on transitioning away from all the witx infrastructure, so unless you have short-term needs, I wouldn't take the current witx organization as something to make major organizational changes for
Kevin Boos (Jun 16 2022 at 00:32):Dan Gohman said:
If you look at crates/wasi-common/src/snapshots/preview_1.rs, you'll see a
wiggle::from_witx!invocation which parses a witx file and generates a trait, and a little further down,impl wasi_snapshot_preview1::WasiSnapshotPreview1 for WasiCtx
Ah, thanks so much! That's exactly what I was looking for, can't believe I missed it.
Last updated: Nov 22 2024 at 17:03 UTC