Refactor singleton and filesystem path handling

- Remove singleton PostCodeDataHolder. It only contained a single int
  which could easily be held inside the main PostCode class instead.
- Simplify D-Bus match construction by using predefined
  PropertiesChanged rule.
- Remove unnecessary PostCode members which were just copies of const
  strings.
- Refactor some filesystem path construction/handling to simplify code.

Tested:
Rebooted host a few times and observed that correct POST code history is
still populated in Redfish.

Signed-off-by: Jonathan Doman <jonathan.doman@intel.com>
Change-Id: Ifd61751807da704eaf2a64dac34ca708fd28c872
3 files changed
tree: 9778c73d5c0a6e1464bd6ad968fedcf6c952cb19
  1. inc/
  2. service_files/
  3. src/
  4. subprojects/
  5. .clang-format
  6. LICENSE
  7. meson.build
  8. meson_options.txt
  9. OWNERS
  10. README.md
README.md

phosphor-post-code-manager

This phosphor-post-code-manager repository provides an infrastructure to persist the POST codes in BMC filesystem & it also owns the systemd services that are responsible for exposing the BIOS Post Codes to rest of the world via redfish.

To Build

To build phosphor-post-code-manager package , do the following steps:

meson <build directory>
ninja -C <build directory>

Hosted Services

This repository ships xyz.openbmc_project.State.Boot.PostCode.service systemd service along with its template version and a tiny binary that exposes the necessary dbus interfaces & methods to extract the POST codes per boot cycle.

Architecture

This repository is tightly coupled with phosphor-host-postd OpenBMC respository which is responsible for emitting the dbus signals for every new POST Code.

phosphor-post-code-manager is architected to look for the property changed signals which are being emitted from the service that hosts Value property on xyz.openbmc_project.State.Boot.Raw interface & archive them per boot on the filesystem, so that those can be exposed over redfish