Hubtools and loading#657
Open
mkeeter wants to merge 4 commits intodelete-old-coresfrom
Open
Conversation
mkeeter
force-pushed
the
hubtools-and-loading
branch
from
16ea8d2 to
fe3feff
Compare
mkeeter
force-pushed
the
hubtools-and-loading
branch
3 times, most recently
from
a80da4f to
f8548f9
Compare
When humility/hubris were first developed we didn't have many details of the hubris archive beyond "it's a zip". We've since developed a separate library for hubris manipulation. Let humility use it too.
mkeeter
force-pushed
the
hubtools-and-loading
branch
from
f8548f9 to
d1f50d6
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
(staged on #656)
This PR is based on #633 (using
hubtoolsfor Hubris archive manipulation), with two changes:The idea behind the second change is simple. In our existing code, we construct a default
HubrisArchive, then incrementally populate it; if you are given aHubrisArchive, you do not know if it is valid or not. This feels like a C-style "allocate then populate" workflow, but is not idiomatic in Rust. This PR changes archive construction so that aHubrisArchiveis valid by the time you get it.To start, the only way to build a
HubrisArchiveis now from ahubtools::RawHubrisArchive. During construction, functions which used to mutate a half-populated archive (taking&mut self) are now methods which return data. Some functions are moved around: constructing theHubrisManifestis moved into methods on that type, instead of on theHubrisArchiveitself. Same for I2C: I introduced a newHubrisManifestI2cConfigandHubrisI2cBusListto contain I2C data and methods for building it. There's a lot of code moving around, but not many logic changes.Along the way, this eliminates the notion of "archive doneness": a
HubrisArchiveis fully populated, and if you don't like that, you can get theRawHubrisArchiveinstead.(Apologies for the size of this PR; I tried to do minimal changes, but each fix required changing something else until I had done the full refactoring)