Parse PELs sent by OpenPOWER host firmware

[Deepak Kodihalli]

Hi,

The SELs/eSELs (System Event Log) that OpenBMC receives from 
hostboot/skiboot today are not interpreted, and are dumped as-is in a 
property of the error log D-Bus object. This means that if there's a PEL 
(Platform Event Log) hidden in the eSEL, admins/users of the error log 
need to depend on external tools to parse the PEL to human readable text.

Here's a proposal to have the BMC itself parse such eSELs (the 
motivation is to make the OpenBMC error logs more useful in this 
context, without needing the extra steps to parse such errors) :

- Separate this from phosphor-logging. This code can't go to a phosphor 
app, because it's OpenPOWER specific. Have, for example, an 
openpower-logging app implement a D-Bus interface to parse out a PEL 
from an eSEL. This app will host it's own D-Bus service.

- Such an app can watch for error D-Bus objects being created in the 
phosphor namespace. If it finds an eSEL in an error log, it can attempt 
to parse a PEL (if there's one), and store the PELs parsed text 
representation in a D-Bus property.

- The app can create a D-Bus object with the same path as the original 
object and have a D-Bus object-manager at the error log root path, so 
that when someone uses the OpenBMC REST API to read an error log, 
properties across all D-Bus services will be returned 
(phosphor-rest-server does this today already). This means with the 
existing REST API to enumerate error logs, a parsed PEL would be 
returned, if present.

- To parse the PEL, use opal-elog-parse.

I have some quickly hacked-up code based on the proposal above, and I 
can submit that for review. In general, this is appearing to me to be 
one of the ways to add host-specific information to phosphor D-Bus 
objects, without breaking the phosphor D-Bus API or changing the REST URIs.

Thanks,
Deepak