Readit Newsphickey commented on Show HN: Munal OS: a graphical experimental OS with WASM sandboxing github.com/Askannz/munal-... · Posted by u/Gazoche
> Not sure how to help with this [...]
I guess not much can be done at the moment: dependencies are often the primary obstacle in porting crates to new targets, and just comparing the list of dependencies of wasmtime vs wasmi gives a pretty good indication of which crate is a bit more careful in this regard:
https://crates.io/crates/wasmtime/33.0.0/dependencieshttps://crates.io/crates/wasmi/0.47.0/dependencies
Wasmtime has many capabilities that wasmi does not, and therefore has more optional dependencies, but the required set of dependencies has been portable to every platform I've targeted so far. If anything does present a concrete issue we are eager to address it. For example, you could file an issue on target-lexicon describing how to reproduce your issue.
phickey commented on Show HN: Munal OS: a graphical experimental OS with WASM sandboxing github.com/Askannz/munal-... · Posted by u/Gazoche
We used fuel metering with wasmtime, but that made everything quite slow, certain things veeery slow.
How is the performance when using fuel with wasmi?
We are considering to use epoch counter, but for now we just turned fuel off.
Wasmtime's epoch system was designed specifically to have a much, much lower performance impact than fuel metering, at the cost of being nondeterministic. Since different embeddings have different needs there, wasmtime provides both mechanisms. Turning epochs on should be trivial if your system provides any sort of concurrency: https://github.com/bytecodealliance/wasmtime/blob/main/examp...
phickey commented on Show HN: Munal OS: a graphical experimental OS with WASM sandboxing github.com/Askannz/munal-... · Posted by u/Gazoche
I'm not the OP, but I have a similar experience with Motor OS: wasmi compiles and works "out of the box", while wasmtime has a bunch of dependencies (e.g. target-lexicon) that won't compile on custom targets even if all features are turned off in wasmtime.
Not sure how to help with this much information but I've built and run wasmtime on some pretty squalid architectures (xtensa and riscv32 microcontrollers among others) but the right collection of features might not be obvious. We can help you find the right configuration on the Bytecode Alliance zulip or the wasmtime issue tracker if you need it.
phickey commented on Show HN: Munal OS: a graphical experimental OS with WASM sandboxing github.com/Askannz/munal-... · Posted by u/Gazoche
I think I was a bit spooked by the examples (https://github.com/bytecodealliance/wasmtime/tree/main/examp...), and the need to implement platform dependencies in C code (which would have complicated the build process). Makes sense since it's a more complex and mature project, but Wasmi on the other hand was just a pure Rust dependency that only required a single line in the Cargo.toml. So in short I went the lazy route :)
All of the C primitives there implemented in (unsafe) Rust, but we built that example for an audience that already had some platform elements in C. We'll try to improve the example so that both integrating with C, and using pure Rust, are covered.
phickey commented on Show HN: Munal OS: a graphical experimental OS with WASM sandboxing github.com/Askannz/munal-... · Posted by u/Gazoche
Thanks! I tried to get wasmtime working but it was too much of a pain to compile in no_std mode, so I settled for wasmi instead.
Wasmtime maintainer here - curious to hear what went wrong, I and several other users of wasmtime have production embeddings under no_std, so it should do everything you need, including building out WASI preview 2 support. You can find me on the bytecode alliance zulip if you need help.
phickey commented on Roto: A Compiled Scripting Language for Rust blog.nlnetlabs.nl/introdu... · Posted by u/gbxyz
Would wasmtime be a good general purpose scripting extension layer for a C program in the style of embedded Lua but faster and more generic? Is that a reasonable use-case?
Wasmtimes C bindings for components are still a work in progress. In general C programming is always going to require more work than Rust programming, due to the limitations of C abstractions, but at the moment it’s also held back by how much energy has gone into the C bindings, which is much less than the Rust bindings which many of the maintainers, myself included, created and are using in production at their day jobs.
More info: https://github.com/bytecodealliance/wasmtime/issues/8036 Several folks have volunteered work on the C bindings over the last year or two, with this contributor making progress most recently: https://github.com/bytecodealliance/wasmtime/pulls?q=is%3Apr...
phickey commented on Roto: A Compiled Scripting Language for Rust blog.nlnetlabs.nl/introdu... · Posted by u/gbxyz
match Plugin::instantiate_async(&mut store, &component, &linker).await {
Ok(plugin) => {
match plugin
.plugin_guest_oncallback()
.call_ontimedcallback(&mut store, &callback_name)
.await
{
Ok(()) => debug!("Successfully called oncallback for {plugin_path:?}"),
Err(e) => warn!("Failed to call oncallback for {plugin_path:?}: {e}"),
}
}
Err(e) => {
error!("Failed to call oncallback for {plugin_path:?}!: {e}");
}
}
If of course I put a wasm file in the plugin folder that doesn't adhere to that definition, that wasm file isn't considered a plugin.
Thanks for using wasmtime! I worked on the component bindings generator you’re using and it’s really nice to see it out in the wild.
To elaborate a bit further: wasmtime ships a [bindings generator proc macro](https://docs.wasmtime.dev/api/wasmtime/component/macro.bindg...) that takes a wit and emits all the code wasmtime requires to load a component and use it through those wit interfaces. It doesn’t just check the loaded component for the string names present: it also type checks that all of the types in the component match those given by the wit. So, when you call the export functions above, you can be quite sure all of the bindings for their arguments, and any functions and types they import, all match up to Rust types. And your component can be implemented in any language!
That's a really cool implementation! I hope I'll have some time soon to have a peek at the code. I am honestly a bit surprised to see that none of the major cloud providers are even thinking to leverage WASM and WASI for serverless...
Azure has shipped Spin as an experiment https://learn.microsoft.com/en-us/azure/aks/use-wasi-node-po... and is investing in Wasmtime and WASI https://opensource.microsoft.com/blog/2025/03/26/hyperlight-... (One author, Yosh, is the co-chair of WASI standards subgroup)
This platform is also based on wasmtime and wasmtime's wasi-http implementation, which I authored, so I'm really proud to see it reused here!
One more plug: I've been working on https://github.com/yoshuawuyts/wstd/ with Yosh and Dan Gohman (creator of WASI) as a nice way to write wasi-http guests in Rust.
What are the min memory requirements for wasmtime/cranelift?
I have run wasmtime on the esp32 microcontrollers with plenty of ram to spare, but I don’t have a measurement handy.