D-Bus interface to provide data to entity manager
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
> 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.
More information about the openbmc