Message registries continuation

[Matt Spinler]

On 6/22/2020 4:16 PM, James Feist wrote:
> On 6/22/2020 1:46 PM, Matt Spinler wrote:
>> Hi James,
>>
>> Something I forgot below - when building up our event logs, I have 
>> about a dozen fields (mostly OEM)
>> that I have to get from the OpenBMC event log's corresponding PEL 
>> (IBM's enterprise log format).
>>
>> PELs aren't on D-Bus for a few reasons, such as they can be several 
>> KB in size and consist of several
>> dozen discrete fields, so that rules out bmcweb getting them that way.
>
> Would doing something like having the fields in the journal with a 
> link to a file work? See this design for more info: 
> https://github.com/openbmc/docs/blob/master/architecture/redfish-logging-in-bmcweb.md
>

I forgot to mention that this would use the existing D-Bus based event 
log code, and just add new fields
to those responses.  At  this point, I don't think I can use the journal 
because I need to ensure the lifetime
of the errors matches that of the event logs on D-Bus and the PELs 
themselves.

>>
>> I do have a shared library that has the PEL APIs I need (PELs 
>> themselves are in files). Is it OK if I
>> just link in that library as needed when a USE_PELs or whatever 
>> option is set?
>> Alternatively, I could also dlopen it I suppose.
>
> There's another thread over here 
> https://lists.ozlabs.org/pipermail/openbmc/2020-June/022082.html 
> happening right now discussing types of logging. As we already have 2 
> forms of logging supported, I'm a little hesitant to the idea of a 
> third without at least some formal direction of what we want logging 
> to look like as a project. More so as we add advanced features on top 
> of logging, it makes it more difficult to support different methods.
>

This would just be an enhancement to the 2nd form that exists today, the 
D-Bus based one, but yea, I can
wait and see how that thread shakes out.


>>
>> Just trying to avoid a surprise during review.
>>
>> Thanks
>>
>