Processing PLDM FRU information with entity manager
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"
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.
More information about the openbmc