[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [MirageOS-devel] Update on capnp-rpc
> 1. The fuzz tests found a race, where messages may get delivered out > of order in some (convoluted) cases. > I asked on the capnp list, and it seems that the C++ reference > implementation doesn't handle this quite right either. > We're investigating a fix, but it's unlikely you'll hit the problem. > See: https://github.com/mirage/capnp-rpc/issues/59 Being able to run fuzz-testing on a complex RPC protocol is really great! The bug that it founds look also quite involved :-) > 2. The API for building requests and responses has a lot of > boilerplate. I'd like to simplify this by modifying capnp-ocaml to > allow attaching capabilities to messages without requiring a separate > type. I have been using the library quite a lot recently and indeed there is a lot of boiler-plate. Generating more code seems indeed sensible. 95% of the client/code is type-driven so I am pretty sure we could auto-generate almost everything with a few annotation to select the right calling convention for instance (to switch between call_for_value and pipeline calls). My latest experiment is to generate client/server bindings for some MirageOS signatures: https://github.com/linuxkit/linuxkit/blob/master/projects/miragesdk/src/sdk/proto.capnp and see the (verbose) client/server code for Mirage_flow_lwt: https://github.com/linuxkit/linuxkit/blob/master/projects/miragesdk/src/sdk/flow.ml > 3. There are some (minor) Unix dependencies in the library and in > capnp-ocaml, which need moving out so we can use it in unikernels. > > 4. Start on level 2 support, which will require the library to be able > to establish secure connections. Currently, it doesn't do any crypto > and so the helpers only allow connections over Unix-domain sockets for > now. > > I'd be interested in feedback from anyone who wants to try it! Thanks for doing that work, I really like 1st class support for passing around functions. It fits very well with turning a random MirageOS signature into an RPC boundary. I really would like to use this to define MirageOS groups of unikernels coordinating via secure RPC over the MirageOS signatures -- I have plans to extend the mirage tool to do this (or at least try) at one point :-) Best, Thomas _______________________________________________ MirageOS-devel mailing list MirageOS-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |