autodidaddict opened Issue #1476:
Looking at the
create_wasi_instance
function, it doesn't accept a list of imports. While the main use case for WASI might be to access the low-level syscalls supported by the interface, we should still be able to build WASI modules that import from the runtime host. The ability to specify imports for a WASI module is a feature that's available on other runtimes.Is there a way using existing public functions to configure imports for a WASI module?
peterhuene commented on Issue #1476:
Accidental transfer of this issue, sorry about that.
I'm going to close this as fixed with the latest API. It is now quite simple to define a WASI implementation with the
Linker
and have host functions that either provide non-WASI imports or override WASI imports with customized implementation.
peterhuene closed Issue #1476:
Looking at the
create_wasi_instance
function, it doesn't accept a list of imports. While the main use case for WASI might be to access the low-level syscalls supported by the interface, we should still be able to build WASI modules that import from the runtime host. The ability to specify imports for a WASI module is a feature that's available on other runtimes.Is there a way using existing public functions to configure imports for a WASI module?
peterhuene edited a comment on Issue #1476:
Accidental transfer of this issue, sorry about that.
I'm going to close this as fixed with the latest API. It is now quite simple to define a WASI implementation with the
Linker
and have host functions that either provide non-WASI imports or override WASI imports with customized implementation.See the linking example for an idea of how that might work. You would link in the WASI instance or define additional host functions with
Linker::define
.Please reopen if you feel this issue was closed in error.
Last updated: Nov 22 2024 at 16:03 UTC