How to use add_to_linker_get_host · wasmtime

I can't quite seem to figure out what to actually provide for the host_getter.

Lann Martin (Jun 18 2024 at 13:39):

Most consumers are expected to use a higher level add_to_linker. If you do need more control over linking, take a look at how add_to_linker works. There is some weird indirection here because we're trying to enable different data access patterns and we've run into limitations in Rust's type system around closures and lifetimes.

Lann Martin (Jun 18 2024 at 13:41):

Note that this is changing again slightly in Wasmtime 22, though again you'll just be able to look at how add_to_linker works to adapt.

Landon James (Jun 18 2024 at 13:47):

Lann Martin (Jun 18 2024 at 13:50):

Lann Martin (Jun 18 2024 at 13:52):

There actually is a variant for that but it is hidden at the moment. Maybe we could expose that.

Lann Martin (Jun 18 2024 at 13:56):

wasi-http: Consider unhiding `add_only_http_to_linker` functions · Issue #8832 · bytecodealliance/wasmtime

These functions allow linking just the types and outbound-handler interfaces without the rest of the proxy world. I'm not sure why they are currently hidden; this seems like a generally useful feat...

Landon James (Jun 18 2024 at 14:04):

Correcr, this is only outgoing http for a WASI compliant http client for the AWS Rust SDK. I’m just bumping our canary to use the latest wasmtime now that all the preview 2 days hints have settled. I think I can probably just add proxy to linker, although it is overkill for my needs.

Landon James (Jun 18 2024 at 14:05):

Would appreciate the greater granularity for linking the http interfaces, especially if I was going to use this in a plugin sort of context where I might want to limit the interfaces provided to run untrusted code

Lann Martin (Jun 18 2024 at 14:40):

You certainly can use add_to_linker_get_host, its just that we are intending/hoping it is can just be a "power user" feature so you can expect more boilerplate and less friendliness :smile:

Landon James (Jun 18 2024 at 17:09):

Ahh now I'm remembering a bit more about why I split these linker bits up originally. Using both:

wasmtime_wasi::add_to_linker_async(&mut linker)?;
wasmtime_wasi_http::proxy::add_to_linker(&mut linker)?;

2024-06-18T16:33:11.682943Z ERROR wasm failed:
import of `wasi:clocks/wall-clock@0.2.0` defined twice

2024-06-18T17:02:25.872804Z ERROR wasm failed:
component imports instance `wasi:cli/environment@0.2.0`, but a matching implementation was not found in the linker

Caused by:
    0: instance export `get-environment` has the wrong type
    1: function implementation is missing

Its been a few months, but I think the reason I was linking every interface in individually is that I kept hitting errors similar to import of 'wasi:clocks/wall-clock@0.2.0' defined twice when trying to use the higher level aggregate linker functions from both the wasmtime-wasi and wasmtime-wasi-http crates.

Stream: wasmtime

Topic: How to use add_to_linker_get_host

Landon James (Jun 18 2024 at 03:00):