Adding support for custom SEL records

[Bills, Jason M]

On 10/19/2022 8:43 AM, Brad Bishop wrote:
> Thanks for the reply Lei Yu.
> 
> On Wed, 2022-10-19 at 10:05 +0800, Lei Yu wrote:
>>
>> 2. The rsyslog way puts the SEL in a file and thus there are no DBus
>> objects, which makes it harder to work with other services.
> 
> Are there other services that work with IPMI sels?  I know there is a
> Redfish SEL log.  Anything else?

bmcweb has a build flag to choose between D-Bus- or journal-based logging.
> 
>> Indeed, but the rsyslog way is not really (and fully) upstream.
> 
> I'm trying to determine which implementation is a better fit for me
> based on the technical merits of the solution, not based on what
> repositories the source code is in.  If that ends up being the rsyslog
> approach, I'd consider helping to move the code and make it fully
> upstream.
> 
> In the hopes that it generates additional information about the
> motivations behind the differing implementations, allow me to ask a
> somewhat rhetorical question.  Jason, to avoid confusing OpenBMC users
> by having to select from two different SEL implementations with pros and
> cons of each that are not obvious, would you accept patches that remove
> the rsyslog based implementation from intel-ipmi-oem (provided the Intel
> metadata is also updated to use the alternative)?  If not, why not?

Intel had a requirement to support storing at least 4000 log entries. 
At the time, we were able to get about 400 entries on D-Bus before D-Bus 
performance became unusable.

That was before dbus-broker, so it could perhaps be better today.  But 
I'm guessing there is still a performance impact and arbitrary log limit 
placed on a system by storing the logs on D-Bus.

This log limit is what will make D-Bus log storage a non-starter for Intel.

I'd also be curious about the reverse question.  Is there any benefit to 
storing logs on D-Bus that makes it a better solution?

At the risk of complicating things more (https://xkcd.com/927/), D-Bus 
was the primary solution when Intel joined.  We created the rsyslog 
approach because of the limitation imposed by D-Bus.  But I know there 
are still those who don't like the rsyslog approach.  Is there a way we 
can now get together and define a new logging solution that is fully 
upstream and avoids the drawbacks of both existing solutions?

> 
> Thanks,
> brad