-
Notifications
You must be signed in to change notification settings - Fork 119
Add host component bindgen macros #376
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
e3d98fa
to
7f21888
Compare
83b4776
to
c11ec7a
Compare
This ensures that setting an execution timeout of 0 disables execution timeouts entirely. This is temporary, as we intend to remove the wall-clock timeout feature from Hyperlight entirely in the near future. Signed-off-by: Lucy Menon <[email protected]>
This is useful to allow host-side code to work on both core Hyperlight sandboxes and wrapped sandboxes like Hyperlight Wasm. Signed-off-by: Lucy Menon <[email protected]>
This is useful to allow host-side code to work on both core Hyperlight sandboxes and wrapped sandboxes like Hyperlight Wasm. Signed-off-by: Lucy Menon <[email protected]>
Signed-off-by: Lucy Menon <[email protected]>
c11ec7a
to
5387278
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I left a couple of minor nits.
This definitely needs a couple of other folks to review but generally I think that this needs two things:
More comments (especially at the method/function level in th hyperlight_comppnent_util crate)
Unit tests
I also have a general question about the parsing of Wasm in order to generate code , why do we do this rather than parse WIT?
.communication_channels | ||
.from_handler_rx | ||
.recv_timeout(self.execution_variables.get_timeout()?); | ||
let timeout = self.execution_variables.get_timeout()?; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: cfg_if!
would probably be better here
@@ -36,15 +85,15 @@ macro_rules! host_function { | |||
/// Register the host function with the given name in the sandbox. | |||
fn register( | |||
&self, | |||
sandbox: &mut UninitializedSandbox, | |||
sandbox: &mut dyn Registerable, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: should we change the name of the variable sandbox
too?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think sandbox is a more descriptive name, since it is some kind of sandbox (whether a hyperlight-core one or a hyperlight-wasm one)
_phantom: core::marker::PhantomData<&'a mut ()>, | ||
} | ||
impl<'a> LentResourceGuard<'a> { | ||
pub fn revoke_nonblocking(&mut self) -> bool { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can this be called multiple times? If so is it worth checking already_revoked
is true at the top?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's semantically a bit nonsensical to call it repeatedly, but I don't think it really matters. The reason why this is here is for a caller that wants to avoid blocking behaviour on Drop
if possible, which is why that flag is set when the nonblocking mutex acquire succeeds.
let path: Option<syn::LitStr> = syn::parse_macro_input!(input as Option<syn::LitStr>); | ||
let path = path | ||
.map(|x| x.value().into()) | ||
.unwrap_or_else(|| std::env::var_os("HYPERLIGHT_WASM_WORLD").unwrap()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could we find a different name for the env var , IMO its a bit strange/confusing that this is called HYPERLIGHT_WASM_WORLD
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about a simpler HYPERLIGHT_WORLD
then?
This commit adds a general implementation of WebAssembly Component Model type elaboration, closely derived from the formal specification. It also adds a number of functions which can generate Rust binding code from appropriately-structured (roughly: WIT-like) component types. Signed-off-by: Lucy Menon <[email protected]>
This adds a proc-macro crate that exposes the bindings code generation from hyperlight_component_util as a macro suitable for using WIT to define a hyperlight host<->guest interface. Signed-off-by: Lucy Menon <[email protected]>
Signed-off-by: Lucy Menon <[email protected]>
5387278
to
1f40391
Compare
This adds a macro that allows generating a host-side interface to a Hyperlight sandbox based on a WebAssembly Component Type (roughly equivalent to a WIT file).