Intel-ipmi-oem repo

[Vernon Mauery]

On 14-Jan-2021 08:38 AM, Ed Tanous wrote:
>On Thu, Jan 14, 2021 at 6:40 AM Brad Bishop <bradleyb at fuzziesquirrel.com>
>wrote:
>
>> On Tue, Jan 12, 2021 at 06:54:14PM -0800, Willy Tu 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.
>> >>
>> >> My 2 cents 😊
>> >
>> >Hi All,
>> >
>> >I guess I'll start working on this if no one has any objection to it.
>>
>> Awesome!
>>
>> >As mentioned in the beginning of the thread. The plan is to break down the
>> >intel-ipmi-oem repo into two parts.
>> >- True OEM at Intel
>> >- Dynamic Sensor stacks (new repo)
>>
>> Why is dynamic sensor stacks a new repo?  I would like to see this done
>> in the existing ipmid repo.  If the default implementations there today
>> are undesired, I'd be fine with seeing those moved to the
>> openpower-ipmi-oem repository.
>>
>
>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.
>
>Would people prefer it to be a package config on IPMID to select between
>the two implementations?

I don't have a problem with a package config to select sensor 
implementations.

>
>>
>> FWIW I would like to make use of dynamic SDR on my new systems (I work
>> for IBM) but I still have to maintain support for Witherspoon, which
>> relies on the old fixed & hardcoded sensor identifiers.

I would say that if IBM is the only company using the sensor 
implementation that is currently in ipmid, it would be best to move it 
to the IBM OEM layer. But it is difficult in a project this size who is 
using what. So leaving it in ipmid for now is fine.

--Vernon