<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jan 14, 2021 at 6:40 AM Brad Bishop <<a href="mailto:bradleyb@fuzziesquirrel.com">bradleyb@fuzziesquirrel.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, Jan 12, 2021 at 06:54:14PM -0800, Willy Tu wrote:<br>
>> Team,<br>
>> Intel-ipmi-oem should be broken and 2 parts, genric and oem specific. I<br>
>see several functionality in this repo like sensors and storage commands<br>
>are generic enough to be used by other platform who is using entity<br>
>manager. So I feel that we should have these functionalities to be moved to<br>
>a separate common repo which can be used by everyone and this repo can only<br>
>contain Intel OEM specific IPMI command support.<br>
>><br>
>> My 2 cents 😊<br>
><br>
>Hi All,<br>
><br>
>I guess I'll start working on this if no one has any objection to it.<br>
<br>
Awesome!<br>
<br>
>As mentioned in the beginning of the thread. The plan is to break down the<br>
>intel-ipmi-oem repo into two parts.<br>
>- True OEM at Intel<br>
>- Dynamic Sensor stacks (new repo)<br>
<br>
Why is dynamic sensor stacks a new repo?  I would like to see this done <br>
in the existing ipmid repo.  If the default implementations there today <br>
are undesired, I'd be fine with seeing those moved to the <br>
openpower-ipmi-oem repository.<br></blockquote><div><br></div><div>I only suggested a new repo originally because today it's a separate repo, and the long ago patch to add it directly to ipmid got the feedback that was too different than the existing to go there.  If we're now ok with it going in IPMID, I'd prefer that as well.</div><div><br></div><div>Would people prefer it to be a package config on IPMID to select between the two implementations?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
FWIW I would like to make use of dynamic SDR on my new systems (I work <br>
for IBM) but I still have to maintain support for Witherspoon, which <br>
relies on the old fixed & hardcoded sensor identifiers.<br>
<br>
-brad<br>
</blockquote></div></div>