wasmtime / issue #10320 Decouple the `wasi.h` API from Wa... · git-wasmtime

Stream: git-wasmtime

Topic: wasmtime / issue #10320 Decouple the `wasi.h` API from Wa...

Wasmtime GitHub notifications bot (Mar 03 2025 at 12:03):

geraintluff opened issue #10320:

Feature

Can the wasi.h API be made generic, so that it only references wasm.h, and not any Wasmtime internals?

It's really close already, and I've detailed the exact changes below make it usable for this situation.

Benefit

Making the WASI API more generic would let users swap the implementation out, supporting straightforward WASI with other engines.

For example, I'm writing a library which uses a WASM engine through the official C API. I'm testing it by linking to Wasmtime, but nothing in my code is Wasmtime-specific, so users could use alternatives (such as Bytecode Alliance's WAMR, which has a smaller binary footprint).

Wasmtime's implementation of the wasi.h API could still be tightly coupled to its wasm.h implementation, (i.e. knowing that wasm_store_t * was a particular Wasmtime class).

I'm writing a C++ implementation of such a WASI module, but it would be awesome to have Wasmtime's one spun out and usable independently, for security and performance reasons.

Implementation

I've added the following changes to Wasmtime's wasi.h:

remove #include <wasmtime/conf.h> and #ifdef WASMTIME_FEATURE_WASI

remove the WASMTIME_ prefixes from the wasi_dir_perms_flags/wasi_file_perms_flags enums.

add a single function to resolve a WASI import:
/**
 * \brief returns a WASI import, or NULL if not supported by the config.
 *
 * The caller is expected to deallocate the returned import.
 *
 * The import is valid only for the lifetime of the supplied config and store.
 */
WASI_API_EXTERN wasm_extern_t * wasi_config_resolve(wasi_config_t *config,
                                                    wasm_store_t *store,
                                                    wasm_importtype_t *type);
Alternatives

Since I can't use an engine-agnostic WASI API, I'm _currently_ writing/using my own C++ library, which provides WASI for any WASM engine.

This would still be useful for other engines which don't (yet) provide their own wasi.h, but being able to use Wasmtime's (fast and secure) WASI implementation without being locked to Wasmtime specifically would be much preferable!

Wasmtime GitHub notifications bot (Mar 03 2025 at 12:40):

geraintluff edited issue #10320:

Feature

Can the wasi.h API be made generic, so that it only references wasm.h, and not any Wasmtime internals?

It's really close already, and I've detailed the exact changes below make it usable for this situation.

Benefit

Making the WASI API more generic would let users swap the implementation out, supporting straightforward WASI with other engines.

For example, I'm writing a library which uses a WASM engine through the official C API. I'm testing it by linking to Wasmtime, but nothing in my code is Wasmtime-specific, so users could link the library to alternatives (such as Bytecode Alliance's WAMR, which has a smaller binary footprint).

I can't (currently) use WASI the same way, so (to be engine-agnostic) I've ended up writing my own C++ WASI implementation. It would be awesome to use Wasmtime's one (for security and performance) when using the Wasmtime engine, by just linking appropriately. Wasmtime's implementation of the wasi.h API could still be tightly coupled to its wasm.h implementation, (i.e. knowing that wasm_store_t * was a particular Wasmtime class).

Implementation

I've added the following changes to Wasmtime's wasi.h:

remove #include <wasmtime/conf.h> and #ifdef WASMTIME_FEATURE_WASI

remove the WASMTIME_ prefixes from the wasi_dir_perms_flags/wasi_file_perms_flags enums.

add a single function to resolve a WASI import:
/**
 * \brief returns a WASI import, or NULL if not supported by the config.
 *
 * The caller is expected to deallocate the returned import.
 *
 * The import is valid only for the lifetime of the supplied config and store.
 */
WASI_API_EXTERN wasm_extern_t * wasi_config_resolve(wasi_config_t *config,
                                                    wasm_store_t *store,
                                                    wasm_importtype_t *type);
Alternatives

Since I can't use an engine-agnostic WASI API, I'm _currently_ writing/using my own C++ library, which provides WASI for any WASM engine.

This would still be useful for other engines which don't (yet) provide their own wasi.h, but being able to use Wasmtime's (fast and secure) WASI implementation without being locked to Wasmtime specifically would be much preferable!

Wasmtime GitHub notifications bot (Mar 03 2025 at 12:40):

geraintluff edited issue #10320:

Feature

Can the wasi.h API be made generic, so that it only references wasm.h, and not any Wasmtime internals?

It's really close already, and I've detailed the exact changes below make it usable for this situation.

Benefit

Making the WASI API more generic would let users swap the implementation out, supporting straightforward WASI with other engines.

For example, I'm writing a library which uses a WASM engine through the official C API. I'm testing it by linking to Wasmtime, but nothing in my code is Wasmtime-specific, so users could link the library to alternatives (such as Bytecode Alliance's WAMR, which has a smaller binary footprint).

I can't (currently) use WASI the same way, so (to be engine-agnostic) I've ended up writing my own C++ WASI implementation, which uses the engine entirely through the WASM C API. It would be awesome to use Wasmtime's one (for security and performance) when using the Wasmtime engine, by just linking appropriately. Wasmtime's implementation of the wasi.h API could still be tightly coupled to its wasm.h implementation, (i.e. knowing that wasm_store_t * was a particular Wasmtime class).

Implementation

I've added the following changes to Wasmtime's wasi.h:

remove #include <wasmtime/conf.h> and #ifdef WASMTIME_FEATURE_WASI

remove the WASMTIME_ prefixes from the wasi_dir_perms_flags/wasi_file_perms_flags enums.

add a single function to resolve a WASI import:
/**
 * \brief returns a WASI import, or NULL if not supported by the config.
 *
 * The caller is expected to deallocate the returned import.
 *
 * The import is valid only for the lifetime of the supplied config and store.
 */
WASI_API_EXTERN wasm_extern_t * wasi_config_resolve(wasi_config_t *config,
                                                    wasm_store_t *store,
                                                    wasm_importtype_t *type);
Alternatives

Since I can't use an engine-agnostic WASI API, I'm _currently_ writing/using my own C++ library, which provides WASI for any WASM engine.

This would still be useful for other engines which don't (yet) provide their own wasi.h, but being able to use Wasmtime's (fast and secure) WASI implementation without being locked to Wasmtime specifically would be much preferable!

Wasmtime GitHub notifications bot (Mar 03 2025 at 13:04):

geraintluff edited issue #10320:

Feature

Can the wasi.h API be made generic, so that it only references wasm.h, and not any Wasmtime internals?

It's really close already, and I've detailed the exact changes below make it usable for this situation.

Benefit

Making the WASI API more generic would let users swap the implementation out, supporting straightforward WASI with other engines.

For example, I'm writing a library which uses a WASM engine through the official C API. I'm testing it by linking to Wasmtime, but nothing in my code is Wasmtime-specific, so users could link the library to alternatives (such as Bytecode Alliance's WAMR, which has a smaller binary footprint).

I can't (currently) use WASI the same way. It would be awesome to use Wasmtime's one (for security and performance) when using the Wasmtime engine, or a more generic fallback one, just by linking differently. Wasmtime's implementation of the wasi.h API could still be tightly coupled to its wasm.h implementation, (i.e. knowing that wasm_store_t * was a particular Wasmtime class).

Implementation

I've added the following changes to Wasmtime's wasi.h:

remove #include <wasmtime/conf.h> and #ifdef WASMTIME_FEATURE_WASI

remove the WASMTIME_ prefixes from the wasi_dir_perms_flags/wasi_file_perms_flags enums.

add a single function to resolve a WASI import:
/**
 * \brief returns a WASI import, or NULL if not supported by the config.
 *
 * The caller is expected to deallocate the returned import.
 *
 * The import is valid only for the lifetime of the supplied config and store.
 */
WASI_API_EXTERN wasm_extern_t * wasi_config_resolve(wasi_config_t *config,
                                                    wasm_store_t *store,
                                                    wasm_importtype_t *type);
Alternatives

To be engine-agnostic, I'm _currently_ writing/using my own C++ library which provides the above API, entirely through the WASM C API so it works with any WASM engine.

Unfortunately, this means I can't use Wasmtime's (fast and secure) WASI implementation unless I put some gnarly Wasmtime-specific #ifdefs in the code.

Wasmtime GitHub notifications bot (Mar 03 2025 at 13:09):

geraintluff edited issue #10320:

Feature

Can the wasi.h API be made generic, so that it only references wasm.h, and not any Wasmtime internals?

It's really close already, and I've detailed the exact changes below which would make it usable for this.

Benefit

Making the WASI API more generic would let users swap the implementation out, supporting straightforward WASI with other engines.

For example, I'm writing a library which uses a WASM engine through the official C API. I'm testing it by linking to Wasmtime, but nothing in my code is Wasmtime-specific, so users could link the library to alternatives (such as Bytecode Alliance's WAMR, which has a smaller binary footprint).

I can't (currently) use WASI the same way. It would be awesome to use Wasmtime's one (for security and performance) when using the Wasmtime engine, or a more generic fallback one, just by linking differently. Wasmtime's implementation of the wasi.h API could still be tightly coupled to its wasm.h implementation, (i.e. knowing that wasm_store_t * was a particular Wasmtime class).

Implementation

I've added the following changes to Wasmtime's wasi.h:

remove #include <wasmtime/conf.h> and #ifdef WASMTIME_FEATURE_WASI

remove the WASMTIME_ prefixes from the wasi_dir_perms_flags/wasi_file_perms_flags enums.

add a single function to resolve a WASI import:
/**
 * \brief returns a WASI import, or NULL if not supported by the config.
 *
 * The caller is expected to deallocate the returned import.
 *
 * The import is valid only for the lifetime of the supplied config and store.
 */
WASI_API_EXTERN wasm_extern_t * wasi_config_resolve(wasi_config_t *config,
                                                    wasm_store_t *store,
                                                    wasm_importtype_t *type);
Alternatives

To be engine-agnostic, I'm _currently_ writing/using my own C++ library which provides the above API, entirely through the WASM C API so it works with any WASM engine.

Unfortunately, this means I can't use Wasmtime's (fast and secure) WASI implementation unless I put some gnarly Wasmtime-specific #ifdefs in the code.

Wasmtime GitHub notifications bot (Mar 03 2025 at 13:10):

geraintluff edited issue #10320:

Feature

Can the wasi.h API be made generic, so that it only references wasm.h, and not any Wasmtime internals?

It's really close already, and I've detailed the exact changes below which would make it usable for this.

Benefit

Making the WASI API more generic would let users swap the implementation out, supporting straightforward WASI with other engines.

For example, I'm writing a library which uses a WASM engine through the official C API. I'm testing it by linking to Wasmtime, but nothing in my code is Wasmtime-specific, so users could link the library to alternatives (such as Bytecode Alliance's WAMR, which has a smaller binary footprint) with no code changes.

I can't (currently) use WASI the same way. It would be awesome to use Wasmtime's one (for security and performance) when using the Wasmtime engine, or a more generic fallback one, just by linking differently. Wasmtime's implementation of the wasi.h API could still be tightly coupled to its wasm.h implementation, (i.e. knowing that wasm_store_t * was a particular Wasmtime class).

Implementation

I've added the following changes to Wasmtime's wasi.h:

remove #include <wasmtime/conf.h> and #ifdef WASMTIME_FEATURE_WASI

remove the WASMTIME_ prefixes from the wasi_dir_perms_flags/wasi_file_perms_flags enums.

add a single function to resolve a WASI import:
/**
 * \brief returns a WASI import, or NULL if not supported by the config.
 *
 * The caller is expected to deallocate the returned import.
 *
 * The import is valid only for the lifetime of the supplied config and store.
 */
WASI_API_EXTERN wasm_extern_t * wasi_config_resolve(wasi_config_t *config,
                                                    wasm_store_t *store,
                                                    wasm_importtype_t *type);
Alternatives

To be engine-agnostic, I'm _currently_ writing/using my own C++ library which provides the above API, entirely through the WASM C API so it works with any WASM engine.

Unfortunately, this means I can't use Wasmtime's (fast and secure) WASI implementation unless I put some gnarly Wasmtime-specific #ifdefs in the code.

Wasmtime GitHub notifications bot (Mar 03 2025 at 13:18):

geraintluff edited issue #10320:

Feature

Can the wasi.h API be made generic, so that it only references wasm.h, and not any Wasmtime internals?

It's really close already, and I've detailed the exact changes below which would make it usable for this.

Benefit

Making the WASI API more generic would let users swap the implementation out, supporting straightforward WASI with other engines.

For example, I'm writing a library which uses a WASM engine through the official C API. I'm testing it by linking to Wasmtime, but nothing in my code is Wasmtime-specific, so users could link the library to alternatives (such as Bytecode Alliance's WAMR, which has a smaller binary footprint) with no code changes.

I can't (currently) use WASI the same way. It would be awesome to use Wasmtime's one (for security and performance) when using the Wasmtime engine, or a more generic fallback one, just by linking differently. Wasmtime's implementation of the wasi.h API could still be tightly coupled to its wasm.h implementation, (i.e. knowing that wasm_store_t * was a particular Wasmtime class).

Implementation

I've added the following changes to Wasmtime's wasi.h:

remove #include <wasmtime/conf.h> and #ifdef WASMTIME_FEATURE_WASI

remove the WASMTIME_ prefixes from the wasi_dir_perms_flags/wasi_file_perms_flags enums.

add a single function to resolve a WASI import:
/**
 * \brief returns a WASI import, or NULL if not supported by the config.
 *
 * The caller is expected to deallocate the returned import.
 *
 * The import is valid only for the lifetime of the supplied config and store.
 */
WASI_API_EXTERN wasm_extern_t * wasi_config_resolve(wasi_config_t *config,
                                                    wasm_store_t *store,
                                                    const wasm_importtype_t *type);
Alternatives

To be engine-agnostic, I'm _currently_ writing/using my own C++ library which provides the above API, entirely through the WASM C API so it works with any WASM engine.

Unfortunately, this means I can't use Wasmtime's (fast and secure) WASI implementation unless I put some gnarly Wasmtime-specific #ifdefs in the code.

Wasmtime GitHub notifications bot (Mar 03 2025 at 16:04):

alexcrichton commented on issue #10320:

Personally I would not recommend using the wasm.h C API. It is less safe and less performant than Wasmtime's custom C API. For this reason I've additionally wanted to historically move in the direction of making wasi.h more like wasmtime/wasi.h and making it Wasmtime-specific. It was originally envisioned as the start of a standard but that hasn't really panned out so we've had various pressures historically pushing in the direction of integrating it more tightly and changing it over time.

which has a smaller binary footprint

This should not be the case in theory, if you find a drastic difference we have documentation on producing minimal builds and if a large different still remains we'd appreciate a bug report!

Wasmtime GitHub notifications bot (Mar 03 2025 at 17:27):

geraintluff commented on issue #10320:

So you reckon the WASM C API is a bad idea, and would prefer each library to be tied to a particular WASM engine?

For what it's worth, if the WASM C API hadn't made it so easy to switch, I would still be using Wasmer. It's what I started with, and it lets you use the JavaScriptCore WebAssembly engine (so you don't even need to ship a compiler/JIT for MacOS).

Wasmtime GitHub notifications bot (Mar 03 2025 at 20:26):

alexcrichton commented on issue #10320:

I'm pointing out that this issue is unlikely to happen in my opinion since we've generally gone in the opposite direction of wasm.h. That does not mean it shouldn't be done nor that it won't be done, just that from my own personal perspective it's probably not worth doing. I don't mean to stifle development of wasm.h or a hypothetical "official" wasi.h either.

The topic of the quality fo the wasm.h API is probably a bit orthogonal to this issue. I brought it up to motivate why I have the rationale I do, but if you'd like to dig into that it's probably best to do so on Zulip for example or in a dedicated location.

Wasmtime GitHub notifications bot (Mar 04 2025 at 10:35):

geraintluff commented on issue #10320:

What (in your opinion) are the chances of _removing_ the wasi.h exports then, and using Wasmtime-only names instead of something that looks like it should be generic?

At the moment, I've had to do some awkward linking tricks to stop the Wasmtime exports from clashing with my own implementation. I like the wasi.h API (with the above changes) and would like to provide something with that API.

Wasmtime GitHub notifications bot (Mar 04 2025 at 10:37):

geraintluff edited a comment on issue #10320:

What (in your opinion) are the chances of _removing_ the wasi.h exports then, and using Wasmtime-only names instead of something that looks like it should be generic?

At the moment, I've had to do some awkward linking tricks to stop the Wasmtime exports from clashing with my own implementation. I like the wasi.h API (with the above changes) and would like to provide something with that interface, particularly if Wasmtime isn't interested in it.

Wasmtime GitHub notifications bot (Mar 04 2025 at 10:37):

geraintluff edited a comment on issue #10320:

What (in your opinion) are the chances of _removing_ the wasi.h exports then, and using Wasmtime-only names instead of something that looks like it should be generic?

At the moment, I've had to do some awkward linking tricks to stop the Wasmtime exports from clashing with my own implementation. I like the wasi.h API (with the above changes) and would like to provide something with that interface, particularly if Wasmtime isn't interested in filling the same gap.

Wasmtime GitHub notifications bot (Mar 04 2025 at 10:44):

geraintluff edited a comment on issue #10320:

What (in your opinion) are the chances of _removing_ the wasi.h exports then, and using Wasmtime-only names instead of something that looks like it should be generic?

At the moment, I've had to do some awkward linking tricks to stop the Wasmtime exports from clashing with my own implementation. I like the wasi.h API (with the above changes) and would like to provide something with that interface - something independent and engine-agnostic, plus a wrapper around Wasmtime-coupled one if possible.

Wasmtime GitHub notifications bot (Mar 05 2025 at 13:56):

geraintluff closed issue #10320:

Feature

Can the wasi.h API be made generic, so that it only references wasm.h, and not any Wasmtime internals?

It's really close already, and I've detailed the exact changes below which would make it usable for this.

Benefit

Making the WASI API more generic would let users swap the implementation out, supporting straightforward WASI with other engines.

For example, I'm writing a library which uses a WASM engine through the official C API. I'm testing it by linking to Wasmtime, but nothing in my code is Wasmtime-specific, so users could link the library to alternatives (such as Bytecode Alliance's WAMR, which has a smaller binary footprint) with no code changes.

I can't (currently) use WASI the same way. It would be awesome to use Wasmtime's one (for security and performance) when using the Wasmtime engine, or a more generic fallback one, just by linking differently. Wasmtime's implementation of the wasi.h API could still be tightly coupled to its wasm.h implementation, (i.e. knowing that wasm_store_t * was a particular Wasmtime class).

Implementation

I've added the following changes to Wasmtime's wasi.h:

remove #include <wasmtime/conf.h> and #ifdef WASMTIME_FEATURE_WASI

remove the WASMTIME_ prefixes from the wasi_dir_perms_flags/wasi_file_perms_flags enums.

add a single function to resolve a WASI import:
/**
 * \brief returns a WASI import, or NULL if not supported by the config.
 *
 * The caller is expected to deallocate the returned import.
 *
 * The import is valid only for the lifetime of the supplied config and store.
 */
WASI_API_EXTERN wasm_extern_t * wasi_config_resolve(wasi_config_t *config,
                                                    wasm_store_t *store,
                                                    const wasm_importtype_t *type);
Alternatives

To be engine-agnostic, I'm _currently_ writing/using my own C++ library which provides the above API, entirely through the WASM C API so it works with any WASM engine.

Unfortunately, this means I can't use Wasmtime's (fast and secure) WASI implementation unless I put some gnarly Wasmtime-specific #ifdefs in the code.

Wasmtime GitHub notifications bot (Mar 05 2025 at 13:56):

geraintluff commented on issue #10320:

OK, so Wasmtime's wasm.h interface actually aborts on a key operation I needed (calling a function by index in a function table), so I can't use it, WASI or not.

Closing as no longer relevant.

Last updated: Apr 18 2025 at 06:04 UTC