Stream: WASI-Virt

Topic: Towards a more dynamic WASI-virt


view this post on Zulip Ryan Levick (rylev) (Apr 26 2024 at 14:36):

@Guy Bedford First, thanks for your work on WASI-virt, and sorry for such a long message.

tl;dr I'm going down a path that will have me rewriting basically all of WASI-virt's virtual adapter component, and I'd like to avoid that if possible. Your insight on if we could get WASI-Virt to do what I need would be super helpful.

I'm working on a testing solution for spin which does a bunch of virtualization (not only of the Spin world but of WASI imports). Right now I'm not using WASI-virt because the virtualization pattern I need differs pretty substantially from how WASI-virt works in a few ways:

My main concern is that WASI-virt has to jump through some interesting hoops to get static configuration working (such as allowing for its read only memory to be changed post-facto) which are all irrelevant in a world of dynamic configuration.

Question: Do you have any thoughts on how difficult it would be to change WASI-virt to allow for this use case?

A utility for testing Spin applications. Contribute to fermyon/spin-test development by creating an account on GitHub.

view this post on Zulip Guy Bedford (Apr 29 2024 at 22:24):

I think I mostly get the use case here, and have a suggestion for how we might map that into an extension of the current WASI Virt architecture. Let me know how the following sounds or if you have further feedback and we can see if we can iterate on an approach here.

Instead of designing for an imported function, what if WASI Virt could export a dynamic configuration update function? So basically it would be a custom export, which at composition time could be configured whether or not it should be exposed to the top-level component exports of the component being virtualized.

Then, this function could take the full configuration scheme for WASI Virt, and update in place its internal static configuration to reflect the dynamic configuration update.

The hard part here mostly seems to be the composition story, but perhaps there's a simple way we could define that when you do a composition of a component with a virtualization, this function could somehow be specially marked in that composition to be directly merged and exposed instead of satisfying the component imports.

Does something like that sound like it would be able to be used for your use case?


Last updated: Dec 23 2024 at 13:07 UTC