Intel-ipmi-oem repo

[Vijay Khemka]

If we can manage this in standard repo with some compile time config parameter to use chosen approach. It will help in maintaining multiple repo.

From: openbmc <openbmc-bounces+vijaykhemka=fb.com at lists.ozlabs.org> on behalf of Ed Tanous <ed.tanous at intel.com>
Date: Tuesday, January 22, 2019 at 2:04 PM
To: "openbmc at lists.ozlabs.org" <openbmc at lists.ozlabs.org>
Subject: Re: Intel-ipmi-oem repo

On 1/22/19 10:16 AM, Vijay Khemka wrote:
Team,
Intel-ipmi-oem should be broken and 2 parts, genric and oem specific. I see several functionality in this repo like sensors and storage commands are generic enough to be used by other platform who is using entity manager. So I feel that we should have these functionalities to be moved to a separate common repo which can be used by everyone and this repo can only contain Intel OEM specific IPMI command support.

When this work was first started, the hope was that the SDR, SEL and the sensor numbering changes could be rolled out to the whole project as the "standard", and that this was just a staging area.  Unfortunately, when we tried to push them, we got some late breaking feedback from the maintainer that some flows (like writing sensor values from the host) would break IBM systems.  Given that our systems didn't require or implement those flows, we didn't have a very clear path forward for how to get them upstreamed, and eventually ran out of time waiting for responses.

The last thread I recall on the issue was here, where the maintainer documented some of the issues that were present on IBM systems with those command sets.  There were several other gerrit reviews that I can find if needed, but they basically boiled down to what's in the thread below.

https://lists.ozlabs.org/pipermail/openbmc/2018-November/014139.html<https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.ozlabs.org_pipermail_openbmc_2018-2DNovember_014139.html&d=DwMDaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=v9MU0Ki9pWnTXCWwjHPVgpnCR80vXkkcrIaqU7USl5g&m=lOhC8y7KcU3Q2RQ4jonrvsNVb2z07MgDTeXIa_NEIF0&s=qW9KX6eEa1B2cCUHKqZRGZtLSb7KCrK9SON3S5AWYG8&e=>

Given that it sounds like the community is interested in these changes being rolled out to more than just intel systems, I suspect we need to continue that discussion.

For reference, the changes being mentioned enable:

1. Dynamic IPMI sensor creation based on dbus mapper reflection, rather than hardcoded paths and sensor numbers.
2. Automatic generation of type 1 SDRs (including M and B scaling) from dbus interfaces.
3. Automatic generation of FRU sdr records based on dbus interfaces.

There are probably other things that I'm forgetting, but these are the highlights.

Tom,

Do you think that you could propose a path that would allow these changes into the mainstream, while still keeping IBM systems functional?  Based on comments that I've heard both in person, and on other gerrit reviews, I believe these changes have some level of support from the other two IPMI maintainers (correct me if I'm wrong guys).



If the final answer is that we really need yet another repo, so be it, I'm happy to help maintain it, but given the interest, we should at least investigate the possibility of making this the "standard" going forward.

My 2 cents 😊
Much appreciated.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20190122/fff71aa5/attachment-0001.html>