Importing a runtime's WASI implementation

[peterhuene]

Have we given any thought to an API for instantiating a module with imports from a runtime's WASI implementation, if one is available?

As an example, Wasmtime has a WASI implementation and also implements the C API. For embedders of Wasmtime using the C API, it would be nice to tell the runtime to automatically import WASI when instantiating a module.

This would preclude the need for an embedder to roll their own WASI implementation when the runtime might already implement one.

[rossberg]

Such a mechanism should be something that can easily be layered on top of this API. I see no particular reason why it would require special engine support. (In fact, something would arguably be wrong with WASI if it did.)

[sbc100]

I think the C API will often be used alongside WASI. Indeed I'm been thinking about writing a small wasi implementation that then uses the C API to load and then modules.

But I think the C API and WASI are complementary and orthogonal.

[peterhuene]

My concern of not having a way to do this via the C API means that it reduces the portability of swapping out one WASI-implementing engine for another from the point of view of the embedder.

We can of course add extra API to do this in Wasmtime, but I feel it's aligned with the intention of the C API to have a standard way of interacting with Wasm engines.

It wouldn't mean that engines have to provide a WASI implementation (the embedder is still free to do so), just that if one is available it could be used.

[sbc100]

My understanding is that the C API, if correctly used within wasmtime, would allow wasmtime's WASI implementation to be engine-agnostic (e.g. you could swap out cranelift for v8 and everything would just work with wasmtime's WASI impl and frontend driver).

I don't see why one would want to consider WASI (or any other APIs) part of the engine. In the same way that JS engines (in general) don't implement web APIs.

[sbc100]

Maybe a higher level API might make sense? wasi-c-api?

[rossberg]

What @sbc100 said. WASI and a Wasm engine are quite separate concepts, and avoiding monolithic structure is a win. Moreover, not all clients of a Wasm engine will have a use for the WASI infrastructure.

[sbc100]

Now that I said it maybe wasi-c-api does make some sense though. It would need to include all of the security, pre-opening FD stuff plus argv and envion stuff, so it would be fairly big API. But perhaps useful? Perhaps we should discuss that in the WASI repo?

[peterhuene]

I think having a wasi-c-api, probably layered on top of wasm-c-api, would make sense and sufficiently solve this problem. At the most fundamental level, I'm looking for a mechanism of asking wasm_instance_new to either automatically include the WASI externs for import (i.e. some wrapping function) or provide a way to get at the externs so that I can instantiate the module with them. Plus a mechanism to set up the security and preopens, too. As an embedder, I'd really like to avoid rolling a WASI implementation (a huge undertaking) if the underlying engine has its own.

I think we can move the discussion there, so I'll open a new issue.