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