Skip to content
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

Move ABI protobuf code to oak_abi crate #764

Closed
daviddrysdale opened this issue Mar 25, 2020 · 1 comment · Fixed by #834
Closed

Move ABI protobuf code to oak_abi crate #764

daviddrysdale opened this issue Mar 25, 2020 · 1 comment · Fixed by #834
Assignees

Comments

@daviddrysdale
Copy link
Contributor

daviddrysdale commented Mar 25, 2020

The ABI is currently focused on the Wasm boundary, and the host function definitions on that boundary – call this "Level 0".

Those host functions typically exchange opaque blobs of data, but in many places these opaque blobs of data are required to have a particular structure – specifically, as protobuf-encoded versions of particular messages:

As such, these protocol buffer definitions also form part of the Oak ABI – call this "Level 1" – and so the generated Rust code for them should live in the oak_abi crate.

Blocked on #668, because the generated code for these messages is currently rust_protobuf-generated, but oak_abi has prost-generated code for other protobuf messages

@daviddrysdale
Copy link
Contributor Author

Not planning to move the StorageService stuff across to oak_abi, because that has a gRPC service definition as well as message definitions. The generated code for gRPC services relies on the oak SDK crate, and so can't be included in the (lower-level) oak_abi crate.

daviddrysdale added a commit that referenced this issue Apr 9, 2020
Protocol buffer messages that are exchanged in serialized form between
Wasm Nodes and Oak-provided pseudo-Nodes are effectively part of the
Oak ABI, so move the generated code for them into the oak_abi crate.

This allows us to remove the oak_runtime->oak dependency that was
introduced by #772.

Along the way, put the gRPC encapsulation protobuf messages into an
`encap` submodule/namespace.

Fixes #764.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant