| commit | 9460809dffb1e7f99cb8b61b9892e968533958b8 | [log] [tgz] |
|---|---|---|
| author | Dhruvaraj Subhashchandran <dhruvaraj@in.ibm.com> | Thu Apr 13 05:55:50 2023 -0500 |
| committer | Dhruvaraj Subhashchandran <dhruvaraj@in.ibm.com> | Tue May 23 07:49:05 2023 -0500 |
| tree | 7a22bdb1b1b1fe7b3645bbd157199a0bdff62a1b | |
| parent | b9f7c1de73ad44c4c6ced7dab8b2a402468cec5d [diff] |
Use createDump method to create different types of BMC dumps There are two create interfaces for phosphor-debug-collector. 1- external create - this interface Which accepts a list of key-value pairs as input, but initially, this was not accepting any parameters. 2- A create interface in phosphor-debug-collector, which accepts the type of the BMC dump and a set of paths to dbus or files to collect as part of dump creation. The internal create is called by core-monitor or ramoops monitor to create BMC dump when the error has occurred, or a core is created, and now there is a new requirement to pass error log id along with these create calls. The internal create is added to pass parameters, and the external one is always assumed as user-initiated. Since now the createDump method is accepting additional parameters, internal create can be removed and both system-generated and user-initiated dumps can use the same interface and method. This commit adds the dump type and enumeration for the types, additionally changing the path parameter from the array of strings to a single string because only for the core dump, there is an attempt to send multiple paths but that can be captured in the packaging script if the folder is sent. Change-Id: Icbeb8499fbdfc1f8919b571495a50867bdcecac1 Signed-off-by: Dhruvaraj Subhashchandran <dhruvaraj@in.ibm.com>
YAML descriptors of standard D-Bus interfaces. The format is described by the sdbusplus binding generation tool sdbus++.
Before defining a new D-Bus interface or modifying an existing one, please read through the documented set of the common requirements and expectations.
This project can be built with meson. The typical meson workflow is: meson builddir && ninja -C builddir.
The meson files used to handle the YAML files are automatically generated and found under the gen subdirectory. When adding or removing YAML files, this must be regenerated. This can be done with the helper script found in the gen subdirectory: cd gen && ./regenerate-meson.
Only the xyz/openbmc_project and org/freedesktop interfaces are built by default. Other interfaces can be enabled by meson options:
-Ddata_com_ibm=true-Ddata_org_open_power=trueExample: meson builddir -Ddata_com_ibm=true && ninja -C builddir