<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>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. <br>
</p>
<p>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). <br>
</p>
<p>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.</p>
<p>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. <br>
</p>
<p>James, Deepak, Patrick - your thoughts ?<br>
</p>
<p><br>
</p>
<p>regards,</p>
<p>Richard<br>
</p>
<p><br>
</p>
<p class="style-scope gr-formatted-text" style="box-sizing:
border-box; margin: 0px 0px 0.8em; padding: 0px; border: 0px;
font-style: normal; font-variant-ligatures: normal;
font-variant-caps: normal; font-variant-numeric: inherit;
font-variant-east-asian: inherit; font-weight: 400; font-stretch:
inherit; font-size: 13px; line-height: inherit; font-family:
Roboto, -apple-system, BlinkMacSystemFont, "Segoe UI",
Helvetica, Arial, sans-serif, "Apple Color Emoji",
"Segoe UI Emoji", "Segoe UI Symbol";
vertical-align: baseline; max-width: 80ch; color: rgb(33, 33, 33);
letter-spacing: normal; orphans: 2; text-align: start;
text-indent: 0px; text-transform: none; white-space: normal;
widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px;
background-color: rgb(255, 255, 255); text-decoration-style:
initial; text-decoration-color: initial;"><span id="output" class="style-scope gr-linked-text" style="box-sizing: border-box; margin: 0px; padding: 0px; border: 0px; font: inherit; vertical-align: baseline; white-space: pre-wrap; overflow-wrap: break-word;">
Say, we want to expose Manufacturer Name, then it can be produced by PLDM FRU application, IPMI Fru based application or even any proprietary application and consumed by applications like Redfish / any other proprietary one. In this way applications can get the data of what ever it is required.
I don't find any data which is different in terms of PLDM FRU / IPMI FRU (ofcourse OEM fields will be there, but that can't be unique), but we need to implement things in common form though.</span></p>
<p class="style-scope gr-formatted-text" style="box-sizing:
border-box; margin: 0px; padding: 0px; border: 0px; font-style:
normal; font-variant-ligatures: normal; font-variant-caps: normal;
font-variant-numeric: inherit; font-variant-east-asian: inherit;
font-weight: 400; font-stretch: inherit; font-size: 13px;
line-height: inherit; font-family: Roboto, -apple-system,
BlinkMacSystemFont, "Segoe UI", Helvetica, Arial,
sans-serif, "Apple Color Emoji", "Segoe UI
Emoji", "Segoe UI Symbol"; vertical-align:
baseline; max-width: 80ch; color: rgb(33, 33, 33); letter-spacing:
normal; orphans: 2; text-align: start; text-indent: 0px;
text-transform: none; white-space: normal; widows: 2;
word-spacing: 0px; -webkit-text-stroke-width: 0px;
background-color: rgb(255, 255, 255); text-decoration-style:
initial; text-decoration-color: initial;"><span id="output" class="style-scope gr-linked-text" style="box-sizing: border-box; margin: 0px; padding: 0px; border: 0px; font: inherit; vertical-align: baseline; white-space: pre-wrap; overflow-wrap: break-word;">Say, ChassisType in IPMI FRU is single byte field, whereas in PLDM FRU it will be of string. But we need to represent the same in well established form (say SMBIOS System /Chassis Type enums).
i.e. Producers (IPMI FRU must change it from one byte type to enum), and PLDM FRU from string to proper enum. Redfish will use this one and accordingly map it to the schema</span></p>
<p><br>
</p>
<div class="moz-cite-prefix">On 5/26/2020 6:26 PM, Deepak Kodihalli
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:5fc67500-b0f4-c964-fc9a-d3f5346e47ab@linux.vnet.ibm.com">On
19/05/20 9:10 am, Deepak Kodihalli wrote:
<br>
<blockquote type="cite">Hi,
<br>
<br>
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.
<br>
<br>
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).
<br>
<br>
From an entity manager perspective, I had few questions :
<br>
- 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)?
<br>
<br>
- 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?
<br>
<br>
[1] <a class="moz-txt-link-freetext" href="https://gerrit.openbmc-project.xyz/#/c/openbmc/docs/+/32532/">https://gerrit.openbmc-project.xyz/#/c/openbmc/docs/+/32532/</a>
<br>
[2]
<a class="moz-txt-link-freetext" href="https://gerrit.openbmc-project.xyz/#/c/openbmc/phosphor-dbus-interfaces/+/32533/">https://gerrit.openbmc-project.xyz/#/c/openbmc/phosphor-dbus-interfaces/+/32533/</a>
<br>
<br>
Thanks,
<br>
Deepak
<br>
<br>
</blockquote>
<br>
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.
<br>
<br>
Very briefly, the proposal was :
<br>
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).
<br>
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).
<br>
<br>
<br>
To do a) above, there are 3 options:
<br>
<br>
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.
<br>
<br>
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.
<br>
<br>
<br>
<br>
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.
<br>
<br>
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.
<br>
<br>
<br>
<br>
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.
<br>
<br>
<br>
Thanks,
<br>
Deepak
<br>
</blockquote>
</body>
</html>