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

[ESI][Cosim] Use ESI native serialization instead of capnp #5918

Open
teqdruid opened this issue Aug 23, 2023 · 2 comments
Open

[ESI][Cosim] Use ESI native serialization instead of capnp #5918

teqdruid opened this issue Aug 23, 2023 · 2 comments
Labels

Comments

@teqdruid
Copy link
Contributor

We currently use Capnp messages for cosim message serialization, but we don't on real hardware. This has been a real source of pain. Let's do away with the Capnp message generation and switch to a blob of data which would be the same as in real hardware.

So the capnp schema would go from what it is today:

interface EsiDpiEndpoint @0xfb0a36bf859be47b (SendMsgType, RecvMsgType) {
  # Send a message to the endpoint.
  send @0 (msg :SendMsgType);
  # Recieve a message from the endpoint. Non-blocking.
  recv @1 (block :Bool = true) -> (hasData :Bool, resp :RecvMsgType);

to

interface EsiDpiEndpoint {
  # Send a message to the endpoint.
  send @0 (msg :Data);
  # Recieve a message from the endpoint. Non-blocking.
  recv @1 (block :Bool = true) -> (hasData :Bool, resp :Data);

And ESI would not be generating a Capnp schema at all. This would also have the side effect of reducing out dependence on Capnp -- which has been an absolute pain -- and longer term replace it with another protocol.

@mortbopet WDYT? I spent an obnoxious amount of time on this (and you spent a long time struggling with it for the C++ API), so while it's cool, I don't see it being worth the upkeep.

@teqdruid teqdruid added the ESI label Aug 23, 2023
@mortbopet
Copy link
Contributor

+1 - If we're confident that ESI will revolve around serialization/deserialization using a schema that's communicated out-of-band/dynamically, then let's just get rid of this and all of the complexity that followed along with it.

@teqdruid
Copy link
Contributor Author

It might make sense to bring this back at some point in the distant future (e.g., for network comms) but at that point we'll probably not be using Capnp since it's not used for software like anywhere.

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

No branches or pull requests

2 participants