Parse PELs sent by OpenPOWER host firmware

[Stewart Smith]

Deepak Kodihalli <dkodihal at linux.vnet.ibm.com> writes:
> 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.

My lack of love for PELs is probably fairly well known, but even if we
replace them down the line, I think there's opportunity here for making
things better for users (including myself).

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

It would be a bonus if we could take different actions based on log
format. If in the future we had a hypothetical other format, it'd be
great if it was *really* easy to plug into OpenBMC. I suspect other
platforms may have similar things (e.g. Google has done protobuf based
logs in the past at least, which are structurally somewhat similar to
PELs but different serialisation format).

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

Is thre any reason for this approach rather than something like
phosphor-logging having a list of properties/formats and external
parsing tools? Kind of like mime type/action lists?

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

+1

-- 
Stewart Smith
OPAL Architect, IBM.