Intel-ipmi-oem repo

[Tom Joseph]

On Wednesday 23 January 2019 03:35 AM, Ed Tanous wrote:
> 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.
>
This is disappointing to hear, feedback was provided as early as May 
2018 and discussed in the community calls earlier that that. 
(https://gerrit.openbmc-project.xyz/#/c/openbmc/s2600wf-misc/+/8521/). 
The major point of concern was arbitrary sensor numbers and the solution 
was a flexible way to assign sensor numbers to sensor D-bus objects.
>
> 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).
>
In the case of SEL we did make progress and reached a consensus. The 
proposed solution was to support mapping sensor number to sensor D-Bus 
object paths in a flexible way(support both arbitrary mapping and 
hardcoded sensor number), so that IBM systems can coexist with the 
proposed SEL architecture. Jason was pursuing that and we haven't heard 
from him for quite some time, this was brought in the community call 
multiple times.

There was OpenPower OEM specific stuff in the standard implementation of 
the SEL and i am done with moving that to the OEM library.

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/20190123/36336d92/attachment-0001.html>