Adding support for custom SEL records
Bills, Jason M
jason.m.bills at linux.intel.com
Thu Oct 20 02:50:47 AEDT 2022
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
> 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?
More information about the openbmc