D-Bus interface to provide data to entity manager (was: Processing PLDM FRU information with entity manager)

[Deepak Kodihalli]

On 19/05/20 9:10 am, Deepak Kodihalli wrote:
> Hi,
> 
> IBM systems have a requirement to consume FRU information sent down via 
> the host firmware and then relay that onto D-Bus (and then onto 
> Redfish). The host firmware will send down FRU information using PLDM.
> 
> We wanted to use entity manager to enable transforming the PLDM FRU data 
> to D-Bus properties that fall under D-Bus inventory interfaces such as 
> the xyz.openbmc_project.Inventory.Decorator.Asset interface. I have an 
> update to the PLDM design doc to capture this flow [1], and some D-Bus 
> interfaces [2] proposed on Gerrit. Would appreciate feedback on the 
> same. The high level idea is that the pldm daemon will host raw PLDM FRU 
> information on D-Bus, and via JSON configs, entity manager can convert 
> those to D-Bus inventory objects (which then can be found by bmcweb).
> 
>  From an entity manager perspective, I had few questions :
> - I see there is provision for persistence, but it looks like applying 
> the persisted information works only if "D-Bus probes" succeed. We have 
> a requirement to make the host-sent inventory information available even 
> when the host is powered off. Now if the host has sent this, then powers 
> off, and then BMC reboots, the BMC will no longer have the raw PLDM FRU 
> information on D-Bus and hence the entity manager probe on the same will 
> fail. Question is, can the probes be made optional when reading the 
> persisted config (system.json)?
> 
> - 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?
> 
> [1] https://gerrit.openbmc-project.xyz/#/c/openbmc/docs/+/32532/
> [2] 
> https://gerrit.openbmc-project.xyz/#/c/openbmc/phosphor-dbus-interfaces/+/32533/ 
> 
> 
> Thanks,
> Deepak
> 

I've got some feedback on the proposal above, which is primarily 
directed at/impacts how the PLDM daemon provides FRU information to the 
entity manager daemon. Wanted to discuss the same here.

Very briefly, the proposal was :
a) The PLDM daemon will parse PLDM FRU format data and host the same on 
D-Bus as a set of PLDM FRU properties (similar to how the FruDevice 
daemon hosts properties under xyz.openbmc_project.FruDevice).
b) Apply EM system/board specific configurations on a) to be able to 
create specific inventory D-Bus objects (this is how EM works today).


To do a) above, there are 3 options:

1) Propose a D-Bus interface in phosphor-dbus-interfaces. This was [2] 
in my original email above. The concern raised by Patrick here is that 
this interface is very specific to a protocol (PLDM in this case), 
whereas the phosphor D-Bus interfaces are mostly abstract and protocol 
agnostic.

In my opinion, PLDM is also a data model, so PLDM specific D-Bus 
interfaces can enable two apps that are PLDM aware (for eg a PLDM 
requester app talking to the PLDM daemon) to talk to each other. I do 
see other protocol specific D-Bus interfaces as well (for eg related to 
SMBIOS). So I don't really understand the concern. The protocol specific 
interfaces do not preclude other abstract interfaces.



2) Propose a generic/abstract 'FRU properties' kind of D-Bus interface. 
This is something that both the PLDM daemon and FRU device daemon could 
use to host FRU information on D-Bus, and to provide the same as an 
intermediate FRU format data to apps like EM. The suggestion on the docs 
commit above [2] was to have an interface like {Enum[Protocol], 
array[byte]}. I think instead this could be a dict[string, 
variant[string, int64]], for a FRU property to value mapping.

While this sounds interesting, are the maintainers of EM and FruDevice 
interested in such an interface? Based on how this interface is 
designed, it might imply changes to FruDevice and Entity Manager. I 
might be interested in chasing this based on the feedback received, and 
if this will really have users other than the PLDM daemon.



3) If everyone thinks option 1 is a bad idea, and if the interest in 
option 2 is limited, I could do this based on how the FruDevice daemon 
and EM interact today, which is based on kind of a private D-Bus 
interface between the two apps. I don't think the Fru device daemon is 
tied up to EM though, it could even be in its own repository.


Thanks,
Deepak