Exposing POST codes

[Tanous, Ed]

I'm not Patrick, but the input on my use cases for this is below.


> So we already have this xyz.openbmc_project.State.Boot.Progress DBus
> interface (and others).  This is what we implemented on POWER.  Can we talk
> about how that API falls short for your use case(s)?  Can I fix it to enable your
> use case(s)?
> 
The enum definition is very limiting, and seems to assume that POST code definitions are the same across all platforms.  New POST codes are added all the time, to the point where even internal teams struggle to keep up with their definitions.  Having an API that would need to be changed for every POST code type seems error prone and very likely to be out of date.
If we adjusted the boot progress interface to be a string rather than an enum, that _could_ meet the use case, but that doesn't seem to be the purpose of that API.

> My concern is I have to at some point implement this API on POWER so that
> POWER can take advantage of applications targeting your new API.
> If doing that would be non-sensical then this probably shouldn’t be an API, or
> at least not in the common xyz namespace.
Isn't this the reason for it being in an API all its own, so it can be optionally included?  I suspect any applications consuming it would likely be logging type applications, and any application using it to take action would be platform specific, even if it were a string.
Does POWER have any way of reporting detailed boot progress?  If, for example, the USB link training starts processor init flows, is that logged in a POWER system?  On x86, it would be logged as a POST code.

> 
> On POWER, this kind of information comes down through the IPMI boot
> progress indicator.  Could someone briefly educate me on what the
> difference between the IPMI boot progress indicator and POST codes are on
> x86?  Is there overlap or are they used for different things?
The POST code indicator is used for very fine grained feedback of boot progress, and is generally not looked at by a user unless there is a problem with boot.  At that point, it is generally (on my systems) used for debug of the system, as it gives some information about what steps the host system took before it failed. 

> 
> It just seems like the first thing anyone is going to do with these numbers is
> look them up and map them to something.  Wouldn’t it make sense to have
> done that mapping already at the API level so that every user and piece of
> code using this API doesn’t have to do it themselves?
That seems like a reasonable assumption, but practically isn't always an option;  In general the POST code mappings are difficult to come by, especially in initial system bringup, and that is when they are most valuable.  If attempted, the ability to provide a mapping should be made optional, which means the proposed interface still needs to exist.

> I think what I’m hinting at here is that you could add a per-platform config file
> to your app that maps the codes to some enumerations in the DBus
> interface, and apply that mapping before you emit the signal. If you wanted
> to go back to numbers later you could just reverse the mapping using the
> same config file.  Please poke holes.

I would argue that this functionality is outside the scope of Patricks patch.  We could very clearly do as you're suggesting, but it would be error prone, and make per-platform configuration more difficult to port, and would likely take a number of months to get correct for all platforms.  As is, Patricks patch adds value outside of his direct platform, as other teams would have an immediate use of it, and is very clear and clean to implement.  Building the platform configurable API you suggest would take a lot more time and effort, for only a little incremental value.  This seems like a case of "Perfect is the enemy of good".  As is, both the API and the daemon are things that I would use today on my platforms.