✔ system-interface v0.22.0 · general

In the past it seems as though all the wasmtime dependencies have been released in lockstep, though in this case I've noticed that the most recent version of wasmtime (0.40.0) isn't compatible with the most recent version of system-interface (0.22.0), because wasmtime has a transitive dependency on system-interface v0.21.0 via wasi-cap-std-sync. Is that intentional?

Dan Gohman (Aug 25 2022 at 15:30):

Can you say more about what you're seeing? Wasmtime doesn't insist that all its dependencies release in lockstep: thiserror, memfd, etc.

Dan Gohman (Aug 25 2022 at 15:40):

The current situation is: if a user of Wasmtime separately depends on system-interface 0.22, they'll get two versions of system-interface. https://github.com/bytecodealliance/wasmtime/pull/4776 is an open PR which updates Wasmtime to system-interface 0.22, so when that lands and is released, this problem will go away. Until then, they can either just accept having multiple versions, or just continue to use 0.21.

Implement the remaining socket-related WASI functions. by sunfishcode · Pull Request #4776 · bytecodealliance/wasmtime

The original WASI specification included sock_read, sock_write, and shutdown. Now that we have some sockets support, implement these additional functions, to make it easier for people porting exist...

bstrie (Aug 25 2022 at 15:44):

In our case, while upgrading to wasmtime 0.40 we can't also update to system-interface 0.22 because we get "expected struct system_interface::fs::fd_flags::FdFlags, found struct system_interface::fs::FdFlags" due to the version mismatch. Which is fine, because it seems like we can just stick with system-interface 0.21 for now (although dependabot still pesters us to upgrade). I just thought it was curious and wondered if perhaps it was a case of forgetting to bump the version in wasi-cap-std-sync.

Notification Bot (Aug 25 2022 at 15:44):

Jamey Sharp (Aug 25 2022 at 17:09):

This sounds like maybe wasi-cap-std-sync should be re-exporting types like FdFlags instead of requiring callers to pull in system-interface and keep its version in sync. Am I missing something?

fitzgen (he/him) (Aug 25 2022 at 17:23):

@Jamey Sharp agreed, almost always better to re-export than to make devs juggle versions themselves

Dan Gohman (Aug 25 2022 at 17:29):

Dan Gohman (Aug 25 2022 at 17:46):

Ok, yeah. So wasi_common already does have its own FdFlags, so that system-interface isn't visible in the public API, and wasi-cap-std-sync does use that in most places. But it appears there are a few places where the system-interface dependency is exposed.

Dan Gohman (Aug 25 2022 at 18:21):

Make wasi-common-std-sync's dependency on system-interface private. by sunfishcode · Pull Request #4784 · bytecodealliance/wasmtime

Change some pub functions which exposed system-interface types to be non-pub. And, change from_sysif_fdflags functions to get_fd_flags functions that take impl AsFilelike arguments instead of syste...

Dan Gohman (Aug 25 2022 at 18:30):

@bstrie From some searching, the one place I found where this issue comes up is here in the enarx repo. I've now posted a Wasmtime PR #4784, and if I haven't missed anything, should allow you to remove the system-interface dependency from enarx and just use the provided get_fd_flags and is_read_write provided by wasi-cap-std-sync on your filelike types.

enarx/tls.rs at 2b330056eaf9759dafb0e9acac4003b36dda4ae0 · enarx/enarx

Enarx: Confidential Computing with WebAssembly. Contribute to enarx/enarx development by creating an account on GitHub.