D-Bus interface to provide data to entity manager

Deepak Kodihalli dkodihal at linux.vnet.ibm.com
Wed May 27 23:58:25 AEST 2020

On 27/05/20 7:20 pm, Thomaiyar, Richard Marian wrote:
> I always view D-Bus interface as a specification / API which can work 
> with different producers / consumers (correct me, if that's not what we 
> intend with D-Bus interface here). Problem with Option 1 is, it will end 
> up in having multiple producers exposing different interface, and 
> thereby consumers(user interface facing applications) of D-Bus must be 
> aware about all the D-Bus interfaces and always requires change.
> Consider, we want to expose ChassisType, then irrespective of PLDM FRU / 
> IPMI FRU / Proprietary FRU, Consumer applications must read it in the 
> same manner. Having different interface / property types, requires 
> update in both the end. PLDM FRU / IPMI FRU can be in common form 
> (except few nit's /OEM's). We need to make sure it is represented in 
> that angle. As of today phosphor-dbus-interfaces doesn't have FRU 
> interface, but it has inventory related interfaces (exposed by 
> Entity-Manager), which is what Redfish uses (i.e. Indirectly the 
> FruDevice exposed interface is hidden by Entity-manager, and inventory 
> interface exposed by entity-manager is used).
> As of today, entity-manager doesn't add Inventory interface 
> automatically for Add-on cards (which doesn't have any json 
> configuration), but needs exposure (say PLDM based Add on card devices 
> will be of this type), but shouldn't be hard to add it anyway.
> Now the question is do we want to expose FRU as a separate interafce to 
> be used in User facing application, or shall we just use Inventory based 
> interface itself ?If inventory itself can be used, then let's go ahead 
> and add more fields to those if missing anything / correct the same 
> accordingly.
> James, Deepak, Patrick - your thoughts ?

I guess there is a difference between FRU and inventory. If inventory 
interfaces could be used directly, why wouldn't the FruDevice or PLDM 
apps directly host inventory objects, why even use EM?

I believe these apps (FruDevice, PLDM daemon) operate at a per FRU 
level, and rely on something like EM to make one or more inventory 
objects based on the FRU data. So that was my option 2, a generic FRU 
properties interface. I'm just not sure at the moment the 
impact/interest of doing something like that and then aligning FruDevice 
and EM to the same.


> regards,
> Richard

More information about the openbmc mailing list