Stream: git-wasmtime

Topic: wasmtime / issue #12301 Add support for serializing `Config`

view this post on Zulip Wasmtime GitHub notifications bot (Jan 09 2026 at 04:33):

gpace1 opened issue #12301:

Feature

Add serialization or some other form of line-wire data type to support transferring wasmtime::Config between devices.

Benefit

(Unless I'm misunderstanding something) In order to cross precompile right now, the wasmtime engine must know the target's configuration of its wasmtime Engine. By providing serialization to Config the compiling device can query the target for their Config and create an Engine using what it received.

In a simple scenario:

1) A and B connect but otherwise A knows nothing about B except that it's has wasmtime
2) B sends its configuration to A
3) A creates an Engine from B's config and precompiles a component for B
4) A sends the precompiled component to B

Without step 2 device A wouldn't know how to configure it's Engine for B. Even when knowing the target for B it seems it still wouldn't fully be aware of everything (not) supported by B (e.g. GC).

Implementation

The simplest would be to derive serde for Config and all inner types.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 09 2026 at 16:03):

alexcrichton commented on issue #12301:

For this we've historically been hesitant to do this for Config directly due to its unstable-representation-nature, but what we do support is wasmtime_cli_flags::CommonOptions supports serde and can be used to create a Config. That means that you can at least deserialize configuration into a Config. Not everything in Config, however, can be represented with Serde.

Would that work for your use case? Or perhaps something built on and/or adjacent to that would work?

view this post on Zulip Wasmtime GitHub notifications bot (Jan 09 2026 at 17:46):

fitzgen commented on issue #12301:

due to its unstable-representation-nature

FWIW, if the wasmtime_cli_flags::CommonOptions approach is not possible, I could potentially be convinced of adding serialization/deserialization to wasmtime::Config itself, with the understanding that it would only be binary compatible with that _exact_ wasmtime version (not something we would make promises about across patch releases) and we would presumably add the version to the encoding and check it on decoding.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 09 2026 at 18:23):

gpace1 commented on issue #12301:

I'm in no rush to have what I requested supported, as for now I've got control over devices A & B in my scenario.

The issue is in the future I would like to support B being from an "infinity-pool" of third-party devices. The vast majority of which will probably be embedded, so I'm predicting there to be quite the variety of configurations.

Running into versioning problems is always going to be an issue, let alone wasmtime what I'm doing has its own issues. Device A will support multiple different versions of wasmtime, and it's perfectly fine for device A to reject B if it doesn't support the version of its configuration.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 09 2026 at 20:39):

alexcrichton commented on issue #12301:

My hunch is what you'll want is wasmtime_cli_flags::CommonOptions and that should work for your approach. That way you can have a configuration file per-configuration/device which is sent to the central server which dispatches based on wasmtime version which then further loads the configuration for the compilation.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 09 2026 at 22:11):

gpace1 closed issue #12301:

Feature

Add serialization or some other form of line-wire data type to support transferring wasmtime::Config between devices.

Benefit

(Unless I'm misunderstanding something) In order to cross precompile right now, the wasmtime engine must know the target's configuration of its wasmtime Engine. By providing serialization to Config the compiling device can query the target for their Config and create an Engine using what it received.

In a simple scenario:

1) A and B connect but otherwise A knows nothing about B except that it's has wasmtime
2) B sends its configuration to A
3) A creates an Engine from B's config and precompiles a component for B
4) A sends the precompiled component to B

Without step 2 device A wouldn't know how to configure it's Engine for B. Even when knowing the target for B it seems it still wouldn't fully be aware of everything (not) supported by B (e.g. GC).

Implementation

The simplest would be to derive serde for Config and all inner types.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 09 2026 at 22:11):

gpace1 commented on issue #12301:

I think you're right and CommonOptions will work for what I want to do.

Last updated: Jan 29 2026 at 13:25 UTC