Ok, we can do that. I already started with an executor some time ago: https://github.com/0xE282B0/runwasi-youki/tree/main/crates/youki-wamr-executor

Ok, I remember where the problems were 😅.

Rust Crate

There is a wamr-sys crate by @rahul-thakoor on crates.io.
Unfortunately it is a bit outdated, but @jturcotte forked it and updated it. However, it did not have WASI enabled, so I forked it again and enabled WASI in this repo.

The wamr-sys crate is just a bunch of rust-bindgen generated bindings. This leads to a lot of unsafe code. I put together a quick draft to outline the problems: 0xE282B0#5

Runwasi

The drafted shim contains a test case which runs the wasi-demo-app:

#[test]
fn test_exec() -> anyhow::Result<()> {
    exec("../../target/wasm32-wasi/debug/wasi-demo-app.wasm");
    Ok(())
}

This already works, it also worked in the youki executor I tried some time ago. However, it does not work in the runwasi shim, because wasm_runtime_init() fails. (probably during the initialization of the memory allocator). We could try to play with the init configuration and may get someone from the WAMR project to get some insights on that problem.

TLDR

In my opinion we would need to:

• (Re)publish the wamr-sys crate
• Create a wamr crate with a safe api
• Debug why the WAMR runtime initialization fails
• Create a PR to the runwasi project for the WAMR shim 🎉

I'm afraid that's a little more than I can spend working on open source projects. 🫣

Is there anyone with a need for WAMR containers, already?
Or is anyone interested in debugging WAMR on runwasi with libcontainer?

I want to reach out to maintainers from Wamr and asking if the community is interested in investing in this work.

Wamr community is very eager to have volunteers to support it. Wamr team would like to provide all technical guidance beside Rust language knowledge.

@lum1n0us do you all have insights about #337 (comment)? Is there another path or are some of those things you can help us with?