Robin Freyler (Nov 16 2022 at 14:35): Robin Freyler (Nov 16 2022 at 14:35):We wanted to implement basic WASI functionality into the wasmi Wasm interpreter to make it more useful to people outside of our bubble. We found that the wasi-common crate was a perfect building ground for this WASI implementation. Always great to reuse previous work instead of reinventing the wheel all over. The README also reads that it is meant as a general WASI implementation and non-runtime specific. However, with this recent commit (https://github.com/bytecodealliance/wasmtime/commit/0290a83502d3778d460a6ee131294603bd575efd) this is no longer the case since wiggle now hard depends on Wasmtime and since wasi-common builds on wiggle now wasi-common is actually a Wasmtime specific WASI implementation.
We already have a wasmi-wasi implementation based on wiggle and wasi-common (https://github.com/paritytech/wasmi/tree/master/crates/wasi) but since those will hard-depend on Wasmtime it is no longer a really useful building block for us. Did I get this right or have I overlooked something? What would you guys recommend us at wasmi side to do ideally? The next best thing I see is to fork wasi-common and perhaps wiggle and make them wasmi specific but that would be a very similar amount of maintenance work than to have our own WASI implementation.
Alex Crichton (Nov 16 2022 at 15:08):This was intentionally done to clean up the internals of wasi-common and wiggle as supporting multiple runtimes was done for Lucet/Wasmtime but was quite a drag historically. The days of wiggle are also numbered as we're looking to transition to *.wit-based tooling as the WASI standard gets defined in terms of the component model rather than the current *.witx-based definitions
Alex Crichton (Nov 16 2022 at 15:08):Not to say that there's not a path to having a wasmtime-less wasi-common again, but it's not clear what such a refactoring would look like to me at least
Robin Freyler (Nov 16 2022 at 15:18):Thanks @Alex Crichton for your reply. So would you agree that wasi-common and wiggle are no longer useful building blocks for other runtimes and therefore we ideally need to build our own WASI implementation from ground up or are there less work-intense alternatives?
Alex Crichton (Nov 16 2022 at 15:19):I don't believe we have a less work-intensive alternative right now, no
Robin Freyler (Nov 16 2022 at 15:19):okay gotcha, thanks!
Robin Freyler (Nov 16 2022 at 15:30):Sorry, one thing: As a short term solution it seems that wiggle 1.0.0 and wasi-common 1.0.0 are the last versions to be non-Wasmtime specific. So I guess it would be the best decision for wasmi for now to build ontop of those outdated versions until we find a better design/idea.
Pat Hickey (Nov 17 2022 at 17:10):Sorry, I had no idea that there were other users of wiggle and wasi-common. Agree with what Alex said, as we move towards components it’s pretty difficult to see how to keep the implementation and interfaces factored separately. It may be possible again once we get to a steady state but it as we transition it would make things considerably more difficult. If you are happy with the features in wasi-common 1.0 I think that using that package for should be fine, and if you need to fork it to bump dependencies hopefully that isn’t too much trouble
Pat Hickey (Nov 17 2022 at 17:48):by the time components (with resource types) land in wasi-common, I basically expect the crate to be an adapter between the way various std/cap-std/cap-rand etc crates provide appropriately sandboxed interfaces to syscalls, and the types that WASI uses to specify those interfaces. basically, it will be a bunch of glue to convert back and forth between those types. at that stage, I don't think there will be much logic left in there that is "runtime independent" in a meaningful way - the WASI types will be the ones generated by wit-bindgen-host-wasmtime-rust today (that crate will be made part of the wasmtime crate itself soon), and they will be structured according to the exact way the wasmtime component runtime works
Pat Hickey (Nov 17 2022 at 17:50):the good news is, since cap-std came into being, the really challenging filesystem sandboxing logic is not even wasi-specific anymore. the cap-std family is pretty stable and wont ever grow a dep on any sort of wasi/wasm specific runtime
Pat Hickey (Nov 17 2022 at 17:52):so, wasmi is welcome of course to continue using wiggle and wasi-common 1.0 as long as it suits you, and fork those as wiggle-wasmi/ wasi-wasmi if/when it becomes necessary. and then if/when you implement a component runtime, I imagine you will end up replacing the wiggle parts with your own wasmi equivalent of wit-bindgen-host-wasmtime-rust, and at that point the remaining parts of wasi-common will just be that translation layer.
Robin Freyler (Nov 22 2022 at 09:40):Hi @Pat Hickey and thanks a lot for your response. Sorry to answer you so lately but I just have not noticed your response until recently. Fortunately we found out that it is even possible to use wasi-common and wiggle version 2.0.0 but we are going to have to stay on those versions for some time. I agree with your roadmap and vision and I can totally understand the decision of the BytecodeAlliance to make wiggle and other WASI related crate Wasmtime specific. Your tech stack is already complex enough! Until the future that you envisioned in your response exists we are probably going to do what you suggested with forking wiggle and wasi-common and hope that maybe in the far future we can have a common shared base implementation again. :)
Last updated: Nov 22 2024 at 16:03 UTC