DynVm Implementation: Dynamically loaded native modules #379
Conversation
|
@mpwarres @kyessenov could one of you look at it? Thanks! |
Nitpicking, but if we're still talking about the NullVM, then I'd rather use "dynamically-loaded NullVM plugins" or similar, instead of adding another name for the NullVM. |
|
@mpwarres @kyessenov Any updates on this? |
There was a problem hiding this comment.
I scanned through it, and it looks reasonable to me. I think you could probably add a few more macros to make it smaller. I like this approach since it's closer to full-Wasm - globals and shared libraries are directly visible in the library binary, and it allows separating the release/code management.
@PiotrSikora A lot of this is mechanical code - I think we just need to have enough test coverage for this to be accepted.
Protryon
force-pushed
the
master
branch
2 times, most recently
from
f1628cd
to
70b1002
Compare
|
@kyessenov @PiotrSikora I've pushed up some tests for DynVM. |
|
This is a very cool approach, let's get this merged. @PiotrSikora @kyessenov @mpwarres any other feedback here? |
|
I'm fine with the PR. Please stamp the approval :) |
fix comments format and lints Signed-off-by: Protryon <[email protected]>
Signed-off-by: Protryon <[email protected]>
Signed-off-by: Protryon <[email protected]>
Signed-off-by: Protryon <[email protected]>
Signed-off-by: Protryon <[email protected]>
This PR adds a variant of NullVm, DynVM, that can load in native modules as dynamically linked modules.
Haven't written any automated tests yet, wanted to check if any design changes were going to be needed first, since the tests are going to be a bit more complicated than NullVM.
We've been testing this internally in an Envoy integration.