I would like to ask why is the ProcessorId.Step type a string? Is there any constraint on it?
Currently OpenBMC uses `uint16_t` to present Step. I am proposing to change that type to `string` due to an issue (unrelated to this discussion). Also this proposal can make `Step` aligned with Redfish.
Thus, we would like to consult the redfish forum first to know why Redfish uses `string` on `Step`. Is there any constraint on it? If not, wouldn't it be easily ambiguous?
It's a string to allow for flexibility with how various CPU architectures might want to represent their data. Specific with x86, it's common when discussing processor ID registers (like the step) with others as hex values, but JSON does not allow hex values to be encoded natively; the pattern we use elsewhere in Redfish is when we want data to be shown in hex, we use a string representation of the hex value. This is a sample from one of our mockups showing this:
If you refer to the Redfish Data Model Specification (https://www.dmtf.org/sites/default/files/standards/documents/DSP0268_2022.3.pdf) there is supplemental documentation provided that shows specific encodings for different CPU architectures (section 22.214.171.124 specifically for "Step"). At this time we only have details filled out for x86. I also see that we don't go so far as to state the value obtained from various CPU registers is to be encoded as a hex string; this is something I think we need to add.
For 1), there is is a gap in the documentation with what to do with the value of "Step" at the end of that pseudocode. It doesn't explicitly state that it's converted to a hex string when building the JSON response.
For 2), that's right, we can't do that at the moment and so it's fairly open-ended. We're reliant on SMEs of other CPU architectures to give us that input, and once we get it, we can add more documentation to cover other things like ARM processors.