FYI (in order to avoid duplicated effort), the remaining hostcalls have been implemented. They are going to be merged to Lucet soon.

@jedisct1 great news!

I’m thinking, given that the implementation of the remaining hostcalls will land in lucet soon, perhaps it’d be good to refocus the efforts on streamlining the lib’s interface so that it could be reused in both lucet and wasmtime projects? I’d be happy to transfer the repo to CraneStation, and make any necessary changes to wasmtime (with @sunfishcode mentoring ofc), and obviously help out in lucet if need be.

In steps, I was thinking of such a plan of action:

1. Transfer repo to CraneStation
2. Agree on Rust safe interface to the lib (i.e., effectively getting rid of pointers in VmContext trait and making the hostcall impls safe)
3. Create a branch in wasmtime that would use the lib thus replacing the majority of wasmtime-wasi functionality (l've done some preliminary work on that in my fork already but needs cleaning and would need to incorporate any changes agreed in 2.)
4. Simultaneously, do the same in lucet

What do guys think @sunfishcode @acfoltzer @jedisct1?

I'm on board at a high level, but the design of the VmContext trait might be tricky. In particular, we recently landed a big change to our context interface that was needed in order to have simultaneous access to the WasiCtx and the instance heap without gross aliasing. Perhaps we can do something similar in the trait?

@acfoltzer sounds good. I’m actually aware of the PR you’ve linked to, and the current trait looks the way it does precisely because of those incompatibilities between lucet and wasmtime. This is not to say that I wouldn’t want to change it, in fact just the opposite since it’s just nasty with all the unsafes flying around. As I’ve mentioned above, I’d be happy to work on wasmtime in order to align both runtimes and hence this crate as much as possible (I’ve already made the first small step here bytecodealliance/wasmtime#138).

I reckon that if we could flesh out an interface that observes lucet’s approach in bytecodealliance/lucet#157, I could work on the necessary changes to wasmtime with some guidance from @sunfishcode. How does that sound to you guys?

On a different note, while we await the implementation of the remaining hostcalls in lucet, could we merge this PR? It'd help my efforts with wasmtime :-)

@kubkon That sounds good to me. I don't yet have a clear picture for the interface here, but we can figure it out as we go. In the meantime, sure, we can merge this PR :-).

Sounds good to me as well!