<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p><br>
    </p>
    <br>
    <div class="moz-cite-prefix">On Wednesday 23 January 2019 03:35 AM,
      Ed Tanous wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:1cf09b78-e1bc-b999-f934-e60bea6a1e1c@intel.com">
      <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
      <div class="moz-cite-prefix">On 1/22/19 10:16 AM, Vijay Khemka
        wrote:<br>
      </div>
      <blockquote type="cite"
        cite="mid:B67393AC-1915-4999-93D9-944EA6D61D2A@fb.com">
        <meta http-equiv="Content-Type" content="text/html;
          charset=utf-8">
        <meta name="Generator" content="Microsoft Word 15 (filtered
          medium)">
        <style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:"Apple Color Emoji";
        panose-1:0 0 0 0 0 0 0 0 0 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:#0563C1;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:#954F72;
        text-decoration:underline;}
span.EmailStyle17
        {mso-style-type:personal-compose;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
span.apple-converted-space
        {mso-style-name:apple-converted-space;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-family:"Calibri",sans-serif;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style>
        <div class="WordSection1">
          <p class="MsoNormal"><span
              style="font-size:11.0pt;color:black">Team,</span><span
              style="color:black"><o:p></o:p></span></p>
          <p class="MsoNormal"><span
              style="font-size:11.0pt;color:black">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.</span><span style="color:black"><o:p></o:p></span></p>
        </div>
      </blockquote>
      <p>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.</p>
    </blockquote>
    This is disappointing to hear, feedback was provided as early as May
    2018 and discussed in the community calls earlier that that.
    (<a class="moz-txt-link-freetext" href="https://gerrit.openbmc-project.xyz/#/c/openbmc/s2600wf-misc/+/8521/">https://gerrit.openbmc-project.xyz/#/c/openbmc/s2600wf-misc/+/8521/</a>).
    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.<br>
    <blockquote type="cite"
      cite="mid:1cf09b78-e1bc-b999-f934-e60bea6a1e1c@intel.com">
      <p>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.<br>
      </p>
      <p><a class="moz-txt-link-freetext"
href="https://lists.ozlabs.org/pipermail/openbmc/2018-November/014139.html"
          moz-do-not-send="true">https://lists.ozlabs.org/pipermail/openbmc/2018-November/014139.html</a></p>
      <p>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.</p>
      <p>For reference, the changes being mentioned enable:</p>
      <p>1. Dynamic IPMI sensor creation based on dbus mapper
        reflection, rather than hardcoded paths and sensor numbers.<br>
        2. Automatic generation of type 1 SDRs (including M and B
        scaling) from dbus interfaces.<br>
        3. Automatic generation of FRU sdr records based on dbus
        interfaces.</p>
      <p>There are probably other things that I'm forgetting, but these
        are the highlights.</p>
      <p>Tom,</p>
      <p>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).</p>
    </blockquote>
    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. <br>
    <br>
    There was OpenPower OEM specific stuff in the standard
    implementation of the SEL and i am done with moving that to the OEM
    library. <br>
    <br>
    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.<br>
    <blockquote type="cite"
      cite="mid:1cf09b78-e1bc-b999-f934-e60bea6a1e1c@intel.com">
      <blockquote type="cite"
        cite="mid:B67393AC-1915-4999-93D9-944EA6D61D2A@fb.com">
        <div class="WordSection1">
          <p class="MsoNormal"><span
              style="font-size:11.0pt;color:black"> </span><span
              style="color:black"><o:p></o:p></span></p>
          <p class="MsoNormal"><span
              style="font-size:11.0pt;color:black">My 2 cents </span><span
              style="font-size:11.0pt;font-family:"Apple Color
              Emoji";color:black">😊</span><span
              style="color:black"><o:p></o:p></span></p>
          <span style="font-size:11.0pt;color:black"></span><span
            style="color:black"><o:p></o:p></span> </div>
      </blockquote>
      Much appreciated.<br>
    </blockquote>
    <br>
  </body>
</html>