System Firmware states on D-Bus

[Thomaiyar, Richard Marian]

Prefer D-Bus conveying details in finer / better manner, rather than 
tying it towards any user facing application like Redfish / IPMI.

i.e. We can define all possible values in D-Bus interface, so that any 
application (common / oem), can try to use the value, rather than value 
not being available in D-Bus. Redfish / IPMI can have conversion logic 
to group the values as per the need.

Regards,

Richard

On 2/24/2020 10:57 PM, Andrew Geissler wrote:
> I sent an email[1] out a while ago about mapping Redfish Host states to
> PLDM Boot values.
>
> Now that we have that design moving, the next question is whether we want
> to try and map these to our current IPMI-based state sensors[2]
> (OperatingSystemState and BootProgress)? These are currently displayed when
> a user does a "obmcutil state" and I see a few other repositories reference
> them for boot status. The openbmc-test suite also uses them fairly extensively
> to verify different boot tests.
>
> If we want to maintain backwards compatibility then we should map the new PLDM
> based boot progress to these two. Mapping them does not seem too difficult.
> I could have phosphor-host-state-manager (which hosts these D-Bus properties)
> listen for changes to the PLDM property and update the two properties
> appropriately. This assumes a system where the system firmware is only
> IPMI or PLDM (not both) since they would not play all that well together.
>
>  From a Redfish API perspective, it will just directly look at the PLDM
> property.
>
> Thoughts?
>
> [1]: https://lists.ozlabs.org/pipermail/openbmc/2020-February/020417.html
> [2]: https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/xyz/openbmc_project/State/Boot/Progress.interface.yaml
>       https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/xyz/openbmc_project/State/OperatingSystem/Status.interface.yaml