Stream: git-wasmtime

Topic: wasmtime / issue #8963 How to get control over filesystem...

Wasmtime GitHub notifications bot (Jul 16 2024 at 13:20):

stevenj opened issue #8963:

Our implementation requires filesystems to be fully controlled, and files come from a VFS not any mounted filesystem.
That means we need to control the low level aspects of filesystem access for WasiP2.

I don't see how that can be achieved, because the only option I see is giving Wasi access to a pre-opened directory, which is 100% off the table for our application. How to use the WaiCtxBuilder, and abstract the necessary filesystem interfaces to the runtime?

Wasmtime GitHub notifications bot (Jul 16 2024 at 14:41):

alexcrichton commented on issue #8963:

For a fully virtual filesystem you won't be using WasiCtxBuilder. You'll want to instead implement the Host traits directly generated in the wasmtime-wasi crate such as this. You'd then call add_to_linker or similarly.

Wasmtime GitHub notifications bot (Mar 21 2025 at 10:03):

Timmmm commented on issue #8963:

It looks like there was once a preopened_virt() function that maybe did this? It seems to have been removed though. :-(

It's a bit of a shame you can't use WasiCtxBuilder - I don't want to have to reimplement all the other APIs it provides too. Perhaps WasiCtx should be broken up into components (stdio, networking, filesystem etc?). Kind of feels like the trait system could solve this.

Wasmtime GitHub notifications bot (Mar 21 2025 at 18:22):

pchickey commented on issue #8963:

We used to have a more dynamic trait system to make this pluggable when wasmtime-wasi was backed by wasi-common, and when we rewrote wasmtime-wasi to detach it from the legacy wasi-common implementation, we got rid of it because it created significant maintenance burden and complexity for very little benefit over using the linker to do the same.

You can still use the linker to define the filesystem interfaces, and use the rest of wasmtime-wasi's linkers to define the rest of wasi based on WasiCtx, and they will interoperate fine as long as your wasmtime::component::bindgen to generate your filesystem traits has the same with settings for the wasi:io package https://github.com/bytecodealliance/wasmtime/blob/main/crates/wasi/src/bindings.rs#L412-L418

Wasmtime GitHub notifications bot (Mar 21 2025 at 20:02):

Timmmm commented on issue #8963:

Ah ok thanks. Sounds a little bit beyond me tbh but I'll have a go. So I wonder get multiple definition linker errors or something like that?

Wasmtime GitHub notifications bot (Mar 24 2025 at 16:42):

pchickey commented on issue #8963:

Symbols will be duplicated if you call the wasmtime_wasi::add_to_linker_* functions directly, because those put all symbols into the linker. If you drop down to using the individual wasmtime_wasi::bindings::<package>::<interface>::add_to_linker_get_host (see https://github.com/bytecodealliance/wasmtime/blob/main/crates/wasi/src/lib.rs#L356-L385 for how these are collected into the whole set for add_to_linker_async), you can add symbols to the linker on a per-interface basis.

Last updated: Apr 18 2025 at 05:03 UTC