host-sp-comms: add event counters #1638
Merged
Conversation
This file contains 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
Currently, the `armv6m-atomic-hack` crate is, to use a technical term, *annoying*. Its extension traits only exist when `#[cfg(armv6m)]` is set. This means that, in downstream crates that wish to _use_ `armv6m-atomic-hack` to support v6m targets, the extension traits may only be imported when `#[cfg(armv6m)]` is set. Because `RUSTFLAGS` cfgs don't propagate across dependency boundaries, this means that _each_ dependent of `armv6m-atomic-hack` must add a build script with a call to `build_utils::expose_m_profile()` so that the cfg is set properly when building for a v6m board. This is, as previously stated, annoying --- especially when using crates like `counters`, whose `#[derive(Count)]` attribute expands to a use of `AtomicU32Ext`, and thus requires any crate that derives `Count` to add a build script. This branch changes `armv6m-atomic-hack` so that the extension traits `AtomicU32Ext` and `AtomicBoolExt` are always defined, regardless of whether `#[cfg(armv6m)]` is set. Now, only the *implementation* of those traits differs based on the presence of the `armv6m` cfg --- if it is not set, an implementation is provided that simply forwards to the corresponding methods on the `AtomicU32` and `AtomicBool` types in libcore. This way, dependents of `armv6m-atomic-hack` can just import the extension traits without needing to add a build script with `expose_m_profile()`; now, only `armv6m-atomic-hack` itself needs the build script. Now, the `armv6m-atomic-hack` crate can no longer be considered annoying.
This branch adds event counters to `host-sp-comms`'s existing 20-element ringbuffer, so that the total number of events can be tracked. In particular, we count the total number of each message variant messages sent and received between the host and SP, and each variant of the `KeyLookupResult`, `KeySetResult`, and `InventoryResult` messages. Depends on #1635.
cbiffle
approved these changes
Mar 13, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This branch adds event counters to
host-sp-comms's existing 20-element ringbuffer, so that the total number of events can be tracked. In particular, we count the total number of each message variant messages sent and received between the host and SP, and each variant of theKeyLookupResult,KeySetResult, andInventoryResultmessages.Depends on #1635.