oxidecomputer / oxidecomputer/hubris

want a bit in `DeviceDescriptionHeader` to indicate if a device is removeable

Open
#2,659 10 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

control-plane-agent fault-management
Dominant language
Rust
Stars
3.6k
Forks
239
Avg merge
1d 12h
Merged PRs (30d)
23

Description

It would be nice if there was a thingy in the inventory response from the SP indicating if a device can be removed. This would allow upstack software like the MGS sensor metrics code (which is rather dumb when it comes to the actual nature of SP devices) to reason about whether that device's identity will ever change as long as the baseboard remains the same. That would enable MGS to cache things like the device's VPD (once we start reading it) if it is not removeable, which in the case of PMBus devices could save the SP from having to do as much as 256B of I2C traffic per PMBus device every time MGS polls sensors.

From a bytes-on-the-wire perspective it would probably make sense to add this to DeviceCapabilities so that it can be represented by one bit. From a "pedantic eliza naming opinions" perspective it feels a bit wacky to say that "REMOVEABLE" is a "capability". I guess you could say "it is capable of being removed" but I have traditionally interpreted "DeviceCapabilities" is the set of things that MGS is capable of commanding the device to do. Whatever.

[!NOTE]
This began its life as an issue on the management-gateway-service repo, but I moved it to Hubris because people clearly never actually look at issues on that repo, as evinced by the fact that it has basically none of the labels we traditionally use to categorize things.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by tracing the inventory response and the DeviceDescriptionHeader and DeviceCapabilities definitions in Hubris. Read how MGS sensor metrics consumes device identity and capabilities, then settle where the removable-device bit belongs and how it is named. Done means the inventory response exposes this information in a compact form that upstack consumers can use.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
embedded-iot
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
48/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.