Exposing POST codes

[Patrick Venture]

On Mon, Mar 5, 2018 at 1:34 PM Tanous, Ed <ed.tanous at intel.com> wrote:

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

Thanks Ed for your thorough response.