iawia002 opened PR #8950 from iawia002:wasi-runtime-config to bytecodealliance:main:
Part of https://github.com/bytecodealliance/wasmtime/issues/8929, the integration of
wasmtime-cliwill be implemented in the next separate PR.close https://github.com/bytecodealliance/wasmtime/pull/8939
close https://github.com/bytecodealliance/wasmtime/pull/8928cc @alexcrichton
iawia002 requested wasmtime-core-reviewers for a review on PR #8950.
iawia002 requested fitzgen for a review on PR #8950.
iawia002 requested wasmtime-default-reviewers for a review on PR #8950.
iawia002 updated PR #8950.
iawia002 updated PR #8950.
alexcrichton submitted PR review:
Thanks! This all looks good to me.
Could this also get hooked up to the CLI as well? Under perhaps
-Sruntime-configand/or some other-Sflags for the actual keys themselves?
alexcrichton submitted PR review:
Thanks! This all looks good to me.
Could this also get hooked up to the CLI as well? Under perhaps
-Sruntime-configand/or some other-Sflags for the actual keys themselves?
alexcrichton created PR review comment:
Could this file also have an assert to ensure that there's a test for all runtime_config tests? Something along the lines of:
fitzgen submitted PR review:
Thanks! A bunch of stylistic/idiomatic/ergonomic suggestions and nitpicks below, but this looks good, and we should be able to land it shortly after those things are addressed.
fitzgen submitted PR review:
Thanks! A bunch of stylistic/idiomatic/ergonomic suggestions and nitpicks below, but this looks good, and we should be able to land it shortly after those things are addressed.
fitzgen created PR review comment:
Is the idea here to separate the configured variables from the per-
Storestate, so that the variables can be reused across manyStores?Can you document that fact?
fitzgen created PR review comment:
I think it would be more ergonomic and idiomatic to turn this function into a
FromIteratortrait implementation, derive theDefaulttrait for this type, makenewreturn the default, and also add afn define(&mut self, key: impl Into<String>, value: impl Into<String>) -> &mut Selfbuilder-style method.
fitzgen created PR review comment:
Can you add a top-level doc comment that describes what this crate does, links to the associated WASI proposal, and provides an example of how to use the crate?
Additionally, can you deny missing documentation for this crate?
//! top-level docs go here... #![deny(missing_docs)] use anyhow::Result;
fitzgen created PR review comment:
And then also rename this to
WasiRuntimeConfig.
fitzgen created PR review comment:
Soft preference to rename this to
WasiRuntimeConfigVariables.
fitzgen created PR review comment:
Isn't this
... + 'staticbound going to mean that you can effectively only useWasiRuntimeConfigView<'static>?If so -- and if the
'staticbound is necessary, which I think it is -- then instead of using lifetimes and borrows betweenWasiRuntimeConfigVariablesandWasiRuntimeConfig, we should makeWasiRuntimeConfiga newtype ofArc<WasiRuntimeConfigVariables>.
fitzgen created PR review comment:
And it would also be nice, for convenience, to
impl<'a> From<&'a WasiRuntimeConfigVariables> for WasiRuntimeConfig<'a> { // ... }You might also want to consider
impl WasiRuntimeConfig<'_> { /// Create a new, empty runtime configuration. pub fn empty() -> WasiRuntimeConfig<'static> { static EMPTY_VARS: WasiRuntimeConfigVariables { /* ... */ }; Self::new(&EMPTY_VARS) } }
fitzgen created PR review comment:
Might as well make this as portable as we can while we are here:
#!/usr/bin/env bash
iawia002 updated PR #8950.
iawia002 submitted PR review.
iawia002 created PR review comment:
The
'staticbound is necessary, but this made me think further, since thewasi-runtime-configAPI is very simple, so I reduced some excessive encapsulation by removingWasiRuntimeConfigVariables/WasiRuntimeConfigCtxand keeping onlyWasiRuntimeConfig. Now, this problem should no longer exists.
iawia002 submitted PR review.
iawia002 created PR review comment:
Is the idea here to separate the configured variables from the per-
Storestate, so that the variables can be reused across manyStores?The idea here is very simple: it's just passing some configuration variables from the runtime to the component. I did add some documentation, but it is not described this way. Please check if the current description is reasonable. Feel free to add more comments.
iawia002 edited PR review comment.
iawia002 commented on PR #8950:
Could this also get hooked up to the CLI as well? Under perhaps
-Sruntime-configand/or some other-Sflags for the actual keys themselves?I made some changes based on all the comments except this one, because I plan to add support for the
wasi-runtime-configAPI towasmtime-cliin a separate PR. Otherwise, this PR would have too many changes, let's focus on thewasi-runtime-configimplementation only in this PR.And I think all comments have been addressed, PTAL.
alexcrichton submitted PR review.
alexcrichton submitted PR review.
alexcrichton created PR review comment:
I don't think that this is the signature that you want because it would imply that every time an import is called it would
.clone()the entireWasiRuntimeConfigstructure which could be pretty expensive.
alexcrichton created PR review comment:
The
+ 'staticdoesn't require<'static>in this case since the+ 'staticonly applies to the lifetime of the captures of the closure itself. This I think was the desired signature which allows borrowing the config without cloning it on import calls.
iawia002 updated PR #8950.
iawia002 submitted PR review.
iawia002 created PR review comment:
Yeah, you are right, I did not understand it correctly last time. I made some changes (https://github.com/bytecodealliance/wasmtime/pull/8950/commits/99b6a113c6a5e13ce3d1a016792b32948ae7d461) and returned to the original
WasiRuntimeConfigVariables+WasiRuntimeConfigstyle. Hope I have understood it correctly this time.
alexcrichton submitted PR review.
alexcrichton merged PR #8950.
fitzgen commented on PR #8950:
Thanks!
iawia002 commented on PR #8950:
Thanks for the review!
Last updated: Dec 13 2025 at 19:03 UTC