Importing a runtime's WASI implementation about wasm-c-api HOT 8 CLOSED

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.)

from wasm-c-api.

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.

from wasm-c-api.

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.

from wasm-c-api.

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.

from wasm-c-api.

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

from wasm-c-api.

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.

from wasm-c-api.

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?

from wasm-c-api.

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.

from wasm-c-api.