D-Bus interface to provide data to entity manager
Deepak Kodihalli
dkodihal at linux.vnet.ibm.com
Thu May 28 01:46:22 AEST 2020
On 27/05/20 8:55 pm, Thomaiyar, Richard Marian wrote:
>
> On 5/27/2020 7:28 PM, Deepak Kodihalli wrote:
>> 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?
>>
> [Richard]: Inventory.Decorator is used in Redfish. i.e. Today Frudevice
> & it's interface exposed is consumed by Entity-Manager alone & Entity
> manager exposes all the needed configuration along with
> Inventory.Decorator.Asset interface. (As you stated, inventory does more
> than what FRU has to expose, but i am trying to see can we use
> Inventory.Decorator itself to expose these needed FRU information?).
> James F ? (Maintainer of both EM & bmcweb)
>
> Current Behavior:
>
> Say - Baseboard fru information is exposed by FruDevice, and Entity
> Manager exposes the sensor or any configuration required for platform A
> or Platform B (based on fru device data). Entity-manager also expose
> Inventory interface which hides the manufacturer name exposed by FRU,
> but exposes the it as Manufacturer in the Inventory interface and
> Redfish uses this).
>
> In case of exposing the PLDM FRU
>
> Option 1:
>
> If we need to rely on PLDM FRU, then Entity-Manager will probe the
> FruDevice data exposed by PLDM FRU daemon, and expose the inventory
> (both for sensor configuration and decorator Asset), we don't change any
> upper layer application. We can follow the same design for the PLDM FRU
> daemon.
Yes, the question remains as to what kind of D-Bus interface does the
PLDM daemon use. Make it's own, similar to xyz.openbmc_project.FruDevice
(which the FruDevice daemon makes), or use a PLDM specific one (for
which I have a patch on Gerrit), or use a common interface that can be
used by both FruDevice and PLDM.
> Note: Currently, it doesn't have a mechanism to expose all the FRU
> devices as Inventory.Decorator interface automatically when there is no
> json configuration for it in EM. This needs to be fixed (say for PLDM
> based Add-on card).
>
> Option 2:
>
> Define new FRU interface (common for both PLDM, IPMI etc.), similar to
> inventory and this itself will be used by both Entity-manager & user
> level interface application (say Redfish).
I didn't intend this to be something that describes inventory, but
rather a common (to PLDM, FruDevice, other apps) alternative to
xyz.openbmc_project.FruDevice, which is what the FruDevice daemon hosts
on D-Bus today. EM can continue to make objects that implement
xyz.openbmc_project.Inventory.Foo interfaces, since they represent
inventory information.
> (Problem with option 2 is it requires changes in Currenr behavior, and
> redfish etc, may need to update it's code to use the common FRU
> interface rather than inventory.Decorator).
>
> Regards,
>
> Richard
>
>> 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.
>>
>> Thanks,
>> Deepak
>>
>>>
>>> regards,
>>>
>>> Richard
More information about the openbmc
mailing list