Add MeasurementKind::Dimensionless

[hawkw]

This commit adds a CpuTctl variant to the MeasurementKind enum. This
is intended to be used to represent AMD CPU T_ctl thermal
values, which are a unitless value from 0-100 representing a kind of
"abstract thermal throttling danger level" --- see
oxidecomputer/hubris#1881 for details on why we need to differentiate
this from other temperature measurements.

[jgallagher]

So, perhaps this ought to be a CpuTctl variant or similar, to specifically represent Tctl measurements. If other dimensionless values show up in future, they would then have their own variant. I'm open to being convicned either way --- what do others think?

I think I'd vote for CpuTctl. Adding Dimensionless means future measurement unit/kinds in the future that don't fit into one of the existing variants have somewhere to land without software changes, which is good, but also feels vague. Presumably two different sensors with the same MeasurementKind are comparable in some way (although that comparison is maybe meaningless and requires more context to know?), but two Dimensionless sensors are definitely not comparable without knowing exactly what they are.

But this is an area well outside where I've been any time recently, so I'm happy to defer to others too. @mkeeter might have opinions too; he worked on the SP <-> IPCC <-> host inventory path with @rmustacc.

[mkeeter]

I'm also weakly in favor of CpuTctl; enum variants are basically free, and it's a weird corner case.

Because this is a change to the SP-MGS protocol, you should also

• Increase CURRENT to 16
• Add a new tests/versioning/v16.rs which tests the serialization of MeasurementKind::Dimensionless

This ensures that we get helpful error reporting if there's a mismatch between SP and MGS; specifically, MGS can report "I failed to serialize this message, but it's on v16 while I'm only on v15, so that's not totally surprising".

[hawkw]

Okay, I think y'all have convinced me that this should be T_ctl-specific. And, thanks @mkeeter for the instructions on how to update the protocol! I'll make those changes shortly.

[hawkw]

Okay, I changed the variant to be just for T_ctl, bumped the version, and added a test.

[mkeeter]

Nit: this could be MeasurementKind::MAX_SIZE

[mkeeter]

Normally, I open a Hubris PR staged against the MGS branch before merging it (to make sure the Hubris integration doesn't require further changes in MGS).

In this case, the change is simple enough that doesn't seem necessary.

[hawkw]

Normally, I open a Hubris PR staged against the MGS branch before merging it (to make sure the Hubris integration doesn't require further changes in MGS).

In this case, the change is simple enough that doesn't seem necessary.

Yeah, I would be quite happy to leave this open until the Hubris-side change is done. But, in this case, I also feel like, well...if fixing this in Hubris actually requires more protocol changes, I'll eat a ST-Link live at Oxcon. :)