Stream: git-wasmtime

Topic: wasmtime / Issue #2573 Adds support for the experimental ...

Wasmtime GitHub notifications bot (Jan 13 2021 at 22:09):

jedisct1 commented on Issue #2573:

@pchickey that would indeed be much cleaner.

The paths have been updated to that layout.

Wasmtime GitHub notifications bot (Jan 13 2021 at 22:34):

jedisct1 commented on Issue #2573:

Unfortunately, with that layout, wasi-crypto becomes part of the workspace, which doesn't allow different versions of the same dependency.

And some of our existing code requires rand_core 0.6, but wasi-crypto dependencies require rand_core 0.5 :(

Wasmtime GitHub notifications bot (Jan 13 2021 at 23:14):

pchickey commented on Issue #2573:

Duplicate dependencies are a mild bummer, and worth the win of having everything in one workspace. thanks!

Wasmtime GitHub notifications bot (Jan 13 2021 at 23:14):

pchickey edited a comment on Issue #2573:

Duplicate rand dependencies are a mild bummer, and worth the win of having everything in one workspace. thanks!

Wasmtime GitHub notifications bot (Jan 13 2021 at 23:36):

jedisct1 commented on Issue #2573:

Unfortunately having different versions appears to be a little bit more than a mild bummer on Windows.

I'm gonna send PRs to have these dependencies updated for rand_core 0.6.

Wasmtime GitHub notifications bot (Jan 19 2021 at 18:38):

jedisct1 commented on Issue #2573:

The implementation can certainly be moved back to the wasi-crypto repository, leaving only the integration bits here.

But it itself requires wiggle. Which is fine, until wasmtime's internal wiggle version diverges from the crates.io version.
Should the wasi-crypto implementation include the entire wasmtime tree as a submodule just to get its wiggle version?

The implementation is also compatible with lucet, but matching the wiggle version has also always been an issue.

What would be a way to solve this?

Wasmtime GitHub notifications bot (Jan 19 2021 at 18:51):

pchickey commented on Issue #2573:

We've struggled with that in wasi-common as well and in the ongoing rewrite, one of the biggest wins we had was breaking out a lot of the implementation into the cap-std family of crates, which take no dependency on wiggle or other Wasmtime project components. Doing this properly required a lot of design work, including introducing the separation of mutable and immutable borrows into wiggle, but ultimately I think it was worthwhile. cap-std defines its own structs, flags, enums and so on, and in many ways these mirror the ones that wiggle can generate from the wasi witx files. In the wasi-common library we impl From to convert back and forth between these types, which is a little noisy, but we trust LLVM to compile these trivial impls down to no-ops, and worthwhile to break the complexity.

Maybe we could spend some time pair programming this week to figure out how an analogous split would work for wasi-crypto?

Wasmtime GitHub notifications bot (Jan 19 2021 at 19:05):

jedisct1 commented on Issue #2573:

This is very helpful, thanks!

And thanks for offering some pair programming time. That may indeed be very useful. I'm going to work on splitting the current wasi-crypto code to see what it takes first.

Thanks to Alex and you!

Last updated: Oct 23 2024 at 20:03 UTC