Skip to content

sim-sp: move version and caboose-related info to update module #8055

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

Merged
merged 8 commits into from
Apr 28, 2025

Conversation

davepacheco
Copy link
Collaborator

This is just an internal refactoring in prep for the next step, which is updating this information during the update process.

There should be only two functional changes here, both minimal:

  • the simulated name field in RoT cabooses used to be SimGimletRot for Gimlets and SimSidecar for Sidecars. I changed the sidecar one to SimSidecarRoT for consistency.
  • rot-boot-details used to report different information than state did (e.g., different fwid). Now they're the same.

Copy link
Member

@hawkw hawkw left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems reasonable to me! It would be nice to get this merged so I can get #7903 updated with these changes --- I'll probably have to go and add accessors for some things that are now hidden behind the SimSpUpdate type.

@davepacheco davepacheco enabled auto-merge (squash) April 28, 2025 16:46
@davepacheco davepacheco merged commit bbac857 into main Apr 28, 2025
17 checks passed
@davepacheco davepacheco deleted the dap/drafts/sp-sim branch April 28, 2025 17:27
hawkw added a commit that referenced this pull request Apr 28, 2025
This necessitates moving the construction of `SpUpdate` earlier in the
sim Gimlet initialization, so that the ereport state can ask it for
Hubris version metadata. Now, it has to be constructed in
`Gimlet::spawn` and passed in to `UdpTask::new` (and thus
`Handler::new`), rather than constructed isnide `Handler::new`, so that
the ereport state can also be passed in to `Handler::new`. @dap, let me
know what you think of this --- if you base additional changes on code
with the current factoring, it will probably make the eventual merge
conflicts between our branches much more unpleasant, so maybe we can
pull this out and land it separately, and have my branch depend on that?
Let me know what you think!
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 this pull request may close these issues.

2 participants