-
Notifications
You must be signed in to change notification settings - Fork 208
minicbor-lease adapter for encoding straight into a lease
#2164
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
Conversation
|
I'd vote to keep it separate! Review to come (either this afternoon or Monday) |
|
@mkeeter opened an upstream issue to make the minicbor API less annoying: twittner/minicbor#36 |
69f16ef to
70e0623
Compare
| [patch.crates-io] | ||
| # See https://gitlab.com/robigalia/ssmarshal/-/merge_requests/2 | ||
| ssmarshal = { git = "https://gitlab.com/de-vri-es/ssmarshal", rev = "10e90cbe389c8f07c52815857551a051946881ab" } |
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.
This is necessary due to ssmarshal no longer compiling with Rust 2024, as when the edition is Rust 2024, serde will require core::error::Error implementations for error types, and ssmarshal doesn't have those.
Since the last commit to ssmarshal's main branch was 8 years ago, I'm not convinced this PR gets merged any time soon. It would probably be worth getting rid of our ssmarshal deps at some point, since Hubpack is basically the same thing but more featureful...
…puter#2164) Based on [a suggestion][1] from @mkeeter, this branch adds an adapter that implements `minicbor::encode::write::Write` for a cursor into a writable lease. This lets us avoid double-buffering in the `read_ereports` path, where we would previously encode each ereport into the receive buffer, and then copy the contents of that into the lease if there is space for it. The new approach avoids the memcpy, and also doesn't encode the ereport in the case where there isn't space left for it. I implemented the lease-writer adapter thing in a separate `minicbor-lease` crate, as I was hoping it would be useful elsewhere...but I'm not actually sure if it will be, now that I think of it: the IPC for delivering an ereport to packrat leases the data _from_ the caller, so callers will just encode into a normal buffer they own. Ah well. [1]: oxidecomputer#2126 (comment)
…puter#2164) Based on [a suggestion][1] from @mkeeter, this branch adds an adapter that implements `minicbor::encode::write::Write` for a cursor into a writable lease. This lets us avoid double-buffering in the `read_ereports` path, where we would previously encode each ereport into the receive buffer, and then copy the contents of that into the lease if there is space for it. The new approach avoids the memcpy, and also doesn't encode the ereport in the case where there isn't space left for it. I implemented the lease-writer adapter thing in a separate `minicbor-lease` crate, as I was hoping it would be useful elsewhere...but I'm not actually sure if it will be, now that I think of it: the IPC for delivering an ereport to packrat leases the data _from_ the caller, so callers will just encode into a normal buffer they own. Ah well. [1]: oxidecomputer#2126 (comment)
Based on a suggestion from @mkeeter, this branch adds an adapter that implements
minicbor::encode::write::Writefor a cursor into a writable lease. This lets us avoid double-buffering in theread_ereportspath, where we would previously encode each ereport into the receive buffer, and then copy the contents of that into the lease if there is space for it. The new approach avoids the memcpy, and also doesn't encode the ereport in the case where there isn't space left for it.I implemented the lease-writer adapter thing in a separate
minicbor-leasecrate, as I was hoping it would be useful elsewhere...but I'm not actually sure if it will be, now that I think of it: the IPC for delivering an ereport to packrat leases the data from the caller, so callers will just encode into a normal buffer they own. Ah well.