Progress Codes in BMC

[Ed Tanous]

On Mon, Feb 1, 2021 at 5:08 PM Brad Bishop <bradleyb at fuzziesquirrel.com> wrote:
>
> 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...

This is what I was hoping to look at before I posted it, so it remains
to be seen how it works.

>
> >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.

Overall, I'm not a huge fan of additionalDataUri in Redfish.  In terms
of redfish, it essentially moves from "this is structured data that
fits X schema" to, "This can be anything you want, and the client
needs to divine the schema out of thin air".  In terms of OpenBMC,
using it a lot worries me, as it seems like it's just there to bypass
the message registry requirement in the schema, and provide an
unstructured interface from an interface that's supposed to be
structured.
With that said, if this is in addition to the structured data, maybe it's ok?

>
> >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?

In a log entry, you'd normally have a message something like

Id: MyCustomPostCodeMessageInTheRegistry
Message: "PostCode 4 happened"
Args: [
   4
]

If automation were reading post codes, it would only be looking at the
ID and Args fields, not the human readable message.  The problem comes
in that the arg itself is an int type, which in nlohmann::json c++ is
a uint64_t.  Technically in the json spec, that int could be a
uint512, and you could declare a custom serializer to do it but you'd
probably run into compatibility problems with other serializers that
can't handle beyond a uint64.

As I'm typing this, there's probably cheats around this, like a hex
encoded string, which I think has a built-in redfish type, but would
be parsed by json just fine.  I'd have to look at the redfish spec to
know for sure.

>
> >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?

The ideal in my mind would be to mock up a strawman LogEntry example,
and see what it looks like.  Considering redfish did add the
additionaDataUri field, I suspect I'm in the minority on not liking
it, so I'm not going to pee into the wind here, but would like to see
what the more structured options look like, and why they're not a
great fit.

>
> >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.

One thing I would like to make sure is that if people _want_ to design
human readable post codes in the future, we haven't backed ourselves
into a corner design-wise.  With that said, I think just having a
unique message id gets us what we need there, but it'd be good to just
keep it in the back of your mind.