Intel-ipmi-oem repo

[Ed Tanous]

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

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/643fd07c/attachment.html>