Processing PLDM FRU information with entity manager

James Feist james.feist at linux.intel.com
Thu May 21 02:56:50 AEST 2020


On 5/20/2020 9:28 AM, Brad Bishop wrote:
> On Tue, 2020-05-19 at 09:10 +0530, Deepak Kodihalli wrote:
> 
> Hi Deepak
> 
>> I see there is provision for persistence, but it looks like
>> applying the persisted information works only if "D-Bus probes"
>> succeed.

There is a PowerState parameter that tells when it can be detected that 
can be used. PowerState="On" things only get removed if detected once 
power is back online.

> 
> This prompted me to take a closer look - as far as I can tell
> system.json is for debugging purposes only.  Maybe James could confirm.

No, the modifiable things are persisted there. Such as thresholds.

> 
> Given this we should probably have an application layer other than
> entity-manager layer be responsible for maintaining the PLDM FRU
> objects on the DBus at the correct time.
> 
>> the BMC will no longer have the raw PLDM FRU information on D-Bus
> 
> I think we have to fix this.  It doesn't feel right that the PLDM FRU
> DBus objects come and go off the bus as the system is powered on/off.
> 
>> How are hierarchical relationships between FRUs supposed to be
>> represented? Is that based on D-Bus pathnames? Or making use of
>> something like the D-Bus Associations interface? Any thoughts on how
>> representing such parent-child relation can be achieved via entity
>> manager configs?
> 
> I'm also hoping James or Richard will let us know what their thoughts
> are for doing this.

I need a better example. FRUs are independent things, so there is no 
hierarchy. Are you talking about Chassis level things? Those are just 
handled by having the right type.

> 
> -brad
> 


More information about the openbmc mailing list