Progress Codes in BMC

[Brad Bishop]

On Mon, Feb 01, 2021 at 04:49:31PM -0800, Ed Tanous wrote:
>Considering that bmcweb already has an LogService implementation to
>access post codes, yeah, log service seems reasonable to represent
>post codes

Nice!  I didn't realize this.  I hope the backend is simply the Boot.Raw 
interface and doesn't require any other applications...

>I  don't see how you're going to fit the vector<uint64_t>
>thing into a log entry

My straw-man thinking was as an additionalDataUri attachment.

>the way that Redfish defines them, you're effectively limited to a
>uint64_t for a numeric argument anyway, 

I'm not following this.  Redfish log entries are limited to a uint64?  
Which property in the LogEntry object are you referring to?

>arbitrary precision, so I'd be interested to see what the proposed log
>entries look like. 

What is the best way to go about making a proposal?  Are additional 
details needed other than I want to stuff all the data in an 
additionalDataUri attachment?

>I was hoping to look into exactly how the existing
>one worked so I could give a better technical answer, but a pointer to
>the code is as good as I can do for the moment.
>https://github.com/openbmc/bmcweb/blob/88b3dd12851cd7bdd4b5c065ba99f40feafb775e/redfish-core/lib/log_services.hpp#L2984
>
>if you're hoping to get human readable post codes, and not just raw
>values, there's probably a discussion that needs to be had about how
>the message registry would work between systems, considering that
>every system implements different post codes, we'd have to switch
>registries dependent on the processor present, and there are likely
>multiple processors in the system, possibly with different post code
>definitions, so the needed configurability explodes a little bit.  If
>you could avoid that, I would.

Agreed - I am not looking for human readable post codes.