| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
| |
Enable the default contructor so that an object can be created
without needing any data.
Also make getValue() const as it is const.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: Id81879e0367edb1055cbf848ed738bc8dd86e953
|
|
|
|
|
|
|
| |
The values are all supposed to be in hex.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: Ic1af46a3505f0f77d6f6f0f1bff998f2ab527522
|
|
|
|
|
|
|
|
|
| |
There was no need for the stream insertion operator, <<,
to take a uint8_t, char, uin16_t, uint32_t, or uint64_t as
a reference as they are small and they aren't being modified.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I9fbf28af7fa6e8e73fd2df8c102e1689647e686d
|
|
|
|
|
|
|
|
| |
Check the SRC ASCII string, and also check the full ID of the last
section object.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: Ie5b5ef3783d316a31e370ef898e11ecaf16b9551
|
|
|
|
|
|
|
|
|
| |
Several testcases use pelDataFactory() for their PEL data. Add SRC,
FailingMTMS, and UserData sections to this data to get some better
coverage.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I2b09fc94c32df1a6fd5bd3cb96c98dc7c3bcc1f2
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit has no functional changes, it just does some things
to make the PEL data creator for testcases, pelDataFactory(), be
more manageable:
- Change to return a plain vector instead of a unique_ptr<vector>.
- Keeps the data for each section in separate vectors and then
either returns those as-is or combines them into a PEL.
- Change the TestPelType enum to TestPELType to match the style guide.
- Have pelDataFactory provide the SRC section instead of srcDataFactory.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I4770aa6a8169e89b6b8f685a9994d845c9e93cfe
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the stream constructor, initialize the member variables to 0 before
unflattening.
This only matters when the data is so short that the 'section count'
field doesn't get initialized and so the code tries to loop through and
unflatten that many optional sections, and since there aren't actually
any it was spitting out extra journal traces about invalid section IDs.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: If08e9ae244d5ade96cafa2160ad9714bebe34551
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This section consists of:
- An 8B header
- 8 4B words of hex data
- Some data is predefined based on the SRC format, some is free format.
- A 32B ASCII character string (The AsciiString class)
- An optional section for FRU callouts (The Callouts class)
Usually, the term SRC (System Reference Code) refers to the contents of
the ASCII string and the hex data words, which can then be looked up in
service documentation to find the meaning of the event log. This PEL
section wraps this pure SRC with additional data like callouts.
This commit only adds support for unflattening the section from an
existing PEL, and flattening it again. Future commits will add support
for creating an SRC from message registry data.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I3dd97c6aca59cc6d6d6fadef84465164090d5658
|
|
|
|
|
|
|
|
|
|
|
|
| |
This Callouts class represents the optional subsection of an SRC PEL
section that contains FRU callouts. It is only present in the SRC when
there are callouts, and it comes at the end of the section.
It is basically just a container for the Callout objects that represent
the actual callouts.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I1d4d95b82f9b4943728d7939e3bf89e4a7bcbb75
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This class represents a single FRU callout in the SRC section of a PEL.
When there are multiple callouts, there will be multiple instances of
this class created. Technically, the callout isn't always a FRU, such
as it could be a maintenance procedure name, but the spec still refers
to this section as the FRU callout section.
The callout priority and location code are in this structure.
There can also be up to one each of three types of substructures
in a single callout:
* FRU Identity (must be first if present)
* Power Controlling Enclosure (PCE)
* Manufacturing Replaceable Unit (MRU)
This commit just provides support for creating this object from a
flattened PEL, such as one that comes down from the host. A future
commit will add support for creating a callout for BMC created event
logs.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I49535285e3cbaa15dfe031648cfaf262380a1cf7
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This substructure is part of the callout subsection in the SRC section
of a PEL, and contains information about Manufacturing Replaceable Units
(MRUs). MRUs are components on a parent FRU (Field Replaceable Unit)
that may be able to be replaced in a manufacturing environment, hence
the name.
This substructure includes a list of <priority, MRU ID> pairs, where the
priority is the same priority value type as used elsewhere in the SRC
section ('H', 'M', 'L', etc), and the MRU ID is a 4B ID that development
will tell manufacturing the meanings of.
This commit only adds support for creating an object from a flattened PEL,
such as one that comes down from the host. A future commit will handle
creating it from scratch for BMC errors.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I6352e1a3cb84db0516902786faca4c387afef411
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This substructure is part of the callout subsection in the SRC section
of a PEL, and contains enclosure information for when another enclosure
controls the power of the failing entity. This would be an unusual
case, when the piece of hardware that is being called out has its power
controlled by another enclosure, for example when an I/O expansion
drawer is connected to 2 servers, and only one of them controls its
power.
This includes:
* The enclosure's name
* The enclosure's machine type, model, and serial number
The BMC will never create this section for BMC errors, but it may need
to unflatten them for PELs sent down from a host that has to deal with
I/O drawers.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: Ie04c1ee3fdfa67ee8666c10fa3bc837f4d33a9ef
|
|
|
|
|
|
|
|
| |
Add << and >> operators to the Stream class for use with a
std::vector<char>.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I22a08bb6518f9aed2385bcdce446a67ea9ea386d
|
|
|
|
|
|
|
|
| |
This class is used by a few other classes, so make it easier to get
data out of it.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I2feb4b83a09e6cb6056c9f1a903ca55e8cacf2ae
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This substructure is part of the callout subsection in the SRC
section of a PEL, and contains information about the FRU (Field
Replaceable Unit) being called out.
This includes:
* The specific type of FRU (see the flags field definitions)
* The FRU part number
* The FRU CCIN value (CCIN = a keyword in VPD).
* The FRU serial number
Instead of just calling out a FRU, this structure can instead be used to
call out a maintenance procedure, which is a string that is used as
a key into the service documentation that maps to a procedure to fix
the problem.
This commit only adds support for creating an object from a flattened PEL,
such as one that comes down from the host. A future commit will handle
creating it from scratch for BMC errors.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: Ic2b9489abea48084116bf2f450bd293c2d655979
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the SRC section of a PEL, there is a field called the 'ASCII string'.
This is the string of 32 characters that shows up on the panel when the
SRC function is chosen, and usually when people refer to an SRC, the
first 8 characters of this field is what they are referring to.
This new class handles that string. It will belong to the SRC section
object.
For BMC error SRCs, it looks like: BDSSRRRR
Where:
BD = "BD", indicating a BMC error SRC
SS = subsystem value from PEL spec
RRRR = reason code of the error
The remaining 24 characters are spaces (' ').
For example:
"BD8D1234 "
For BMC power* related errors, the value is:
"11001234 "
Where the difference is the "11" instead of "BD", and the following
2 bytes are always "00".
* 'power' means comes from the repository that monitors for power
faults. This is different purely to help keep field service
documentation the same as in previous IBM server generations.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I6e7292e7f5b501428999781b1a5ee5c243a63ac6
|
|
|
|
|
|
|
|
|
|
| |
object-mapper.md is moving under architecture/ as part of
https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/26250/
26250 should merge before this is merged.
Change-Id: I4b6d06cd308bae8ebce0ba9ca3c84273e3283a42
Signed-off-by: Gunnar Mills <gmills@us.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
| |
This class is used for accessing the UserData section of a PEL.
This section contains free format data that can be identified by the
component ID, subtype, and version fields in the section header.
Signed-off-by: Aatir Manzur <aatrapps@gmail.com>
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I1223f84353e81202d1ff63c00f3d926cda4994e5
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now that the Generic section object has been introduced so there are
objects for every section, a flatten can be done by flattening every
object inside the PEL and the previous workaround to save the original
raw data can be removed.
This also adds a test case that uses a real PEL from a previous
generation of systems to flatten to give some better coverage than just
using hand coded PEL sections.
A side affect of this is that the PEL constructors that take the raw
data cannot take a const vector of data, as the Stream class that will
be used to read from the vector cannot take a const. Testcases have
been updated to ensure this data is not modified.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I64ae1d1d4a742c80e14666d6b2a6e1e0efd5fd62
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When unflattening a PEL, create objects for every PEL section in the
log. It will use a factory method to choose which object type to create
based on the section ID in the section header. All of these object will
go into a vector of Section objects, which is the base class for every
PEL section class.
The factory will default to creating a Generic object when it doesn't
have any other type to create.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: Ief0e4df5c586a46cea66ca47b4479e3444815309
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This object will be created when unflattening a PEL when there is no
other class to use for that section. It just contains a vector<uint8_t>
for its data.
This is done so that the code can always have objects for all PEL
sections, which helps in validating (can at least ensure every section
has a valid header and size), printing (will always have an object to
get its data to at least hex dump), and re-flattening (no need to keep
around the original data buffer).
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I2b79feb4abc0f44179bdb8eab950f0d274e4e472
|
|
|
|
|
|
|
|
| |
Add << and >> operators to the Stream class for use with a
std::vector<uint8_t>.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I9656ee4e34840d311148e6a701131b3420e62d25
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add a constructor to the PEL class so it can be built from the message
registry entry for that error along with the event log properties.
When support for new sections are added, they will be created here as
well along with the PrivateHeader and UserHeader section classes.
Eventually, this constructor will be called from the Manager class after
it is told a new event log has been created and after it looks up that
error's PEL message registry entry.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I2d8ca550736aab45a30ac3db9861723b33e6cd32
|
|
|
|
|
|
|
|
|
|
|
| |
Add a constructor to the UserHeader section class so it can be built
from the message registry entry for that error along with the event log
severity.
This will be used when creating PELs from OpenBMC event logs.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I7e432f59de7b3f0ba77c3e5887ed5ec3f442ed44
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add a function to map the OpenBMC event log severity values to PEL
severity values.
When creating a PEL from an OpenBMC event log, the event log will have
its own severity property, and if the PEL message registry entry for
that error doesn't supply its own severity (it's optional), use this
function to come up with the PEL severity value to use.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I66aa001265d8acadb165de874e4ade03a8e28007
|
|
|
|
|
|
|
|
|
|
| |
Add a constructor to the PrivateHeader class so it can be built from the
creator's component ID, the OpenBMC log ID, and the creation timestamp.
This will be used when creating PELs from OpenBMC event logs.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I2d1217b9ff0317195366bee50fa72953fd5341dc
|
|
|
|
|
|
|
|
| |
The SRC (System Reference code) is a section in the PEL and several of
its fields are sourced from the message registry.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I4ca7d18a8225f2667b762015c6fd74bfb59d70ff
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The message registry is a JSON file that holds data required to create a
PEL out of an OpenBMC event log. It includes fields like 'subsystem',
'event type', 'action flags', 'SRC reason code', etc.
Many fields in the message registry are optional, and a very minimal
entry make look like:
{
"Name": "xyz.openbmc_project.Power.Error.Fault",
"Subsystem": "power_supply",
"ActionFlags": ["service_action", "report"],
"SRC":
{
"ReasonCode": "0x2030"
}
}
This commit adds support to look up a message registry entry based on an
OpenBMC event log's 'Message' property (i.e.
xyz.openbmc_project.Power.Error.Fault) and then fill in a structure with
the fields found. Future commits will fill in the SRC related fields,
as well as actually create the PEL.
The message registry file can be found on the BMC at:
/usr/share/phosphor-logging/pels/message_registry.json.
For testing, users can put their own message_registry.json in
/etc/phosphor-logging, and that will take precedence.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: Ie4195ed7e58ab6a231271f6b295e63b1d0a4cd78
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add tables that allow one to go between how a PEL field actually shows
up in the PEL (raw bytes) and how it shows up in the message registry (a
string enumeration). The tables also have a column to show a string
description of that value that can be used by the parser, though for now
those descriptions are all left at "TODO".
There only needs to be a table for a PEL field when there is a
corresponding message registry field that is a string enumeration, so
that when code looks up an error in the message registry it knows what
to fill in the PEL with.
Also provide APIs to look up a row in the table by either the PEL value
or the message registry value.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: Iac849bcd2b0449a8d03fac7eb067484e91d28259
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This PEL section contains the Machine Type-Model and Serial number of
the enclosure and is required for BMC PELs. In the constructor that
creates the section from scratch, it gets those values from the
DataInterface class.
This commit doesn't hook this section into the PEL class as there are
some prerequisites that still need to be done first.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I24d679b57751afb00539691defef180191ea8fc7
|
|
|
|
|
|
|
|
|
| |
These will eventually need to be known to a piece of code that
unflattens a PEL into the appropriate section class objects based on the
section ID field in the PEL data.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I90b9d4be49b2e3807a620745fa663f94f7f4e62c
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are PEL fields that contain information that must be obtained from
various places throughout the BMC, such as the machine type/model/SN
from VPD, a few types of codes levels, etc.
Create a DataInterface class that will provide the APIs for collecting
this information. It has an abstract base class so that its functions
can be mocked to return specific data in test cases.
This commit provides APIs to read and present the machine type-model and
machine serial number. These will be used in the FailingMTM and
ExtendedUserHeader PEL sections.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: Iec41fea8d9510ba711475154f019bd59f0028d2e
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This class represents the (M)achine (T)ype-(M)odel (S)erial number
structure for the PEL, where it is used in both the ExtendedUserHeader
and FailingMTMS sections.
It consists of an 8 byte machine type+model field of the form TTT-MMMM,
followed by a 12 byte machine serial number field. Unused bytes are set
to 0.
Note that this is not a PEL section itself. It's just used by other PEL
sections.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I15f9858e951a913ab2353cf93b7f20cc2709c502
|
|
|
|
|
|
|
|
| |
Describe the new xyz.openbmc_project.Logging.Create API that
can be used to create event logs.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: Iaa02e4a6abeb7ce929577b47ab0e518a9ce00638
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A new association interface is defined in phosphor-dbus-interfaces
It would be nice to move the local version of the interface
to the new one.
The behavior of how association work is described here:
https://github.com/openbmc/docs/blob/master/object-mapper.md#associations
Partially resolves openbmc/openbmc#3584
Tested: Create a new log using the Create interface, see that
org.openbmc.Associations has been replaced by the xyz one and
2 association objects are created by the mapper.
Signed-off-by: John Wang <wangzqbj@inspur.com>
Change-Id: I9bcddd4765b12224967383bab2dbaa6d273e2790
|
|
|
|
|
|
|
|
|
| |
UserHeader::validate() had some extra return statements
that aren't needed. It is desired for the function to run
all the way through even on a validation failure.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I9b99970179cd7c84a0201b7d67e39b0bee209beb
|
|
|
|
|
|
|
|
| |
Use *-libtool instead of the arm-specific one to make
`git status ` clean when building with the x86/arm sdk.
Signed-off-by: John Wang <wangzqbj@inspur.com>
Change-Id: If4f734cf89e62a48c1187e5a6937e8b6ebfd5497
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To prepare for supporting PEL sections that can be in any order,
which will probably be stored in a std::vector<unique_ptr<Section>>,
add a pure virtual function in the Section base class so this list
of sections can just be iterated on and have every object in it
flattened.
This flatten() call replaces the operator<<(Stream&, <object>)
functions currently in use, so also convert the operator>> to
unflatten() to make things consistent.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: Id68f16fe4197b389a8495c21539a64f9f583c800
|
|
|
|
|
|
|
|
| |
Add a new BCD time conversion function which will be used in a future
commit to convert an OpenBMC event log timestamp into BCD time.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I08f585d1663bf2d2f73d42b8716756d8c7e3559e
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Each error log commit forces a journal sync and needs to wait for the
sync to occur before allowing the commit to continue. The loop managing
the journal sync was only performing 2 iterations where the first
requests the sync and the second configures the inotify watch. However,
the polling necessary to wait for the inotify would never occur. This
bumps the managing loop to 3 iterations to allow the polling to occur on
the 3rd iteration.
Tested:
The 5sec polling section of code is run on the 3rd iteration
Change-Id: If12c5b33849843b33bb252efd1eb88e0bc954d6d
Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Create an empty set when there is no elog lookup meta data instead of
defaulting to add a single empty string entry.
Tested:
Built image and verified empty string no longer in errors where no
meta data is defined.
Change-Id: I7bf1ff2ab18f174d4cfa78cf22eeac4918033148
Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A journal entry is produced for failure to find empty string meta data
for elogs due to an empty string entry within the generated elog lookup
source. This empty string is due to error yamls that do not contain any
meta data entry of their own and only inherit from another error yaml.
An example of the journal entry for the empty string meta data that is
removed with this fix::
CODE_LINE=76
CODE_FUNC=helper_log
_SYSTEMD_SLICE=system.slice
CODE_FILE=../git/phosphor-logging/log.hpp
MESSAGE=Failed to find metadata
TRANSACTION_ID=4016514682
META_FIELD=
SYSLOG_IDENTIFIER=phosphor-log-manager
_PID=181
_COMM=phosphor-log-ma
_EXE=/usr/bin/phosphor-log-manager
Tested:
Built image and verified empty string entry no longer generated on
errors without meta data but inherit meta data from other error yaml
Change-Id: I3c8745acd86173873827cd59eb6e8d4f687b0e1b
Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
|
|
|
|
|
|
|
|
| |
The elog-lookup-template-mako.cpp was missing from the required package
files to be able to generate the elog lookup source.
Change-Id: Id10759367a0c4012239597c7a471e38f52bfec07
Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds the xyz.openbmc_project.Logging.Create interface on the
/xyz/openbmc_project/logging path. The interface provides a single
method, Create, that allows one to create an event log.
This is an alternative to using the report/commit functions provided by
the phosphor-logging/elog.hpp header file.
Unlike those report/commit interfaces, this does not require that the
entries in the AdditionalData event log property be defined ahead of
time, as the whole AdditionalData contents are just passed in instead of
read out of the journal. This means that the error does not need to
have been defined in the error and metadata YAML files for an event log
to be successfully created. The discussion on if that is still desired
anyway is outside the scope of this commit.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: Icf3f740ab86605deeaeb955ff51aa2ef292f5af4
|
|
|
|
|
|
|
|
|
| |
In preparation for adding another function to create a log entry, factor
out some common code into a new function that will be able to be called
in both spots.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I8881f4ec0d36a2b2e2b1897b63d524022a328286
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add the getPELData() function on the Repository class to return
PEL data based on a PEL ID or OBMC event log ID.
The intended use for this will be a D-Bus method, mainly used for
debug via the REST interface, to get the PEL data off the BMC when
only the OpenBMC event log ID is known, which will be the case until
the Redfish APIs are ready.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: Ia1d8bff627992fae16be9136f2814f01ea69009e
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When someone deletes an OpenBMC event log, the corresponding PEL should
also be deleted. This commit adds support for that by keeping an
internal map of the IDs to the files that contain the PEL data in the
repository in order to find the file to remove. This will then get
called in the phosphor-logging extension's delete hook.
The actual map key is a structure of both the PEL ID and OpenBMC log ID,
so either can be used to find a PEL in the repository, which will be
useful in other cases, for example for retrieving PEL data based on the
PEL ID.
As the map needs to match the actual repository file contents, it will
get built on startup, and modified when PELs are added and removed.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I33bb96da297c770e175c5c6b19705dda1c8766b6
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Create the Repository class that can save PELs in (and later retrieve
them from) the filesystem. It provides an add() method that can add
a PEL object to the repository.
Now, when the Manager class sees an OpenBMC event log created with the
RAWPEL metadata in the AdditionalData property that points at a file
that contains a PEL, it can save that PEL. Before the PEL is saved, the
log ID and commit timestamp fields in the PEL will be updated - the log
ID to a unique value, and the timestamp to the current time.
Change-Id: I8dbaddf0f155bcb6d40b933294ada83feb75ce53
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This class represents a Platform Event Log.
A PEL consists of sections, and this commit just adds support for the
only required sections - the Private Header and User Header, by
including those specific objects. More will be added in the future.
The only constructor provided in this commit is to construct the object
from an existing flattened PEL buffer. This is for use in the case when
a PEL is received from off the BMC, such as from the host. Future
commits will add support for creating PELs from OpenBMC event logs.
Since there aren't objects yet for every PEL section, the class cannot
make a full flattened PEL without still keeping around the original PEL
data it received in the constructor as mentioned above. So for now it
will keep that data and just overlay the sections it does support when
flattening. In the future, a fully formed PEL will be able to be
constructed from just flattening the section objects in the correct
order.
This commit provides a few public methods of note:
* data() - returns a flattened PEL
* assignID() - sets a unique ID in the log ID field in the Private
Header
* setCommitTime() - Sets the commit timestamp in the Private Header
to the current time
* valid() - Says if the PEL is properly formed
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I2a9d82df9cd096ce77ecca7b2f73b097b8368aa2
|
|
|
|
|
|
|
|
|
|
|
|
| |
Create generatePELID() to return a unique 4B PEL ID every time it is
called. It will start at a base value, and then increment by 1 each
time. It uses a file to save the next value to use.
This will be used by the PEL handling code to create unique values
for the error log ID field in the Private Header section.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I841a8dcc5dc48e2b663004be3dccfb114ba366f2
|