summaryrefslogtreecommitdiffstats
path: root/test/openpower-pels/Makefile.include
Commit message (Collapse)AuthorAgeFilesLines
* PEL: Add ability to create event logsMatt Spinler2020-02-141-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are cases where the PEL code wants to be able to create OpenBMC event logs (and thus PELs) for problems it encounters when trying to create or import other PELs. For example, if the host were to send down a malformed PEL, this code would like to create a new event log and capture part of that bad PEL in the new PEL for debug purposes, as the malformed PEL cannot be reported anywhere since it is malformed. To handle this, create the EventLogger class that provides a log() function that allows the PEL extension code to create OpenBMC event logs (and thus PELs) from within. The underlying function to do the event log creating is passed in via the constructor so that it can be changed for testing. The sd_event_add_defer function (wrapped by sdeventplus) is used to dispatch the creation of a single event, so that the entry point is from the event loop. If there are still events left on the queue after that, then they will be also be scheduled with sd_event_add_defer so that the events are always created from event loop calls. EventLogger does not allow events to be added to the queue if it is being done from within the creation function so that the code can't get stuck in a loop of creating a new event every time an event is created. Signed-off-by: Matt Spinler <spinler@us.ibm.com> Change-Id: I6a9062074dc62cfb6043139ff0a9f3dfcd06c708
* PEL: Print Failing MTMS section into JSONHarisuddin Mohamed Isa2020-02-071-0/+10
| | | | | | | | | | | | | | | | | Remove any trailing whitespace for serial number. "Failing MTMS": { "Section Version": "1", "Sub-section type": "0", "Created by": "0x4552", "Machine Type Model": "OPWR-131", "Serial Number": "1318ABA" }, Testing: Manually run peltool and verified output. All unit tests passed. Signed-off-by: Harisuddin Mohamed Isa <harisuddin@gmail.com> Change-Id: I7a05790bdf406ef6d7946ffae831a45ee6dd5cda
* PEL: Print SRC section into JSONHarisuddin Mohamed Isa2020-02-031-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For BMC created errors, look up the reason code in the message registry for error description and also meaning of data stored in hexwords 6-9 (if any). Added registry message field in peltool list output. "Primary SRC": { "Section Version": "1", "Sub-section type": "1", "Created by": "0x1000", "SRC Version": "0x02", "SRC Format": "0x55", "Power Control Net Fault": "False", "Error Details": { "Message": "PS 0x64 had a PGOOD Fault", "PS_NUM": "0x64" }, "Valid Word Count": "0x09", "Reference Code": "BD8D1001", "Hex Word 2": "00000055", "Hex Word 3": "00000010", "Hex Word 4": "00000000", "Hex Word 5": "00000000", "Hex Word 6": "00000064", "Hex Word 7": "00000000", "Hex Word 8": "00000000", "Hex Word 9": "00000000" } "Primary SRC": { "Section Version": "1", "Sub-section type": "0", "Created by": "0x4552", "SRC Version": "0x02", "SRC Format": "0x2008000", "Power Control Net Fault": "False", "Valid Word Count": "0x04", "Reference Code": "B2001020", "Hex Word 2": "02008000", "Hex Word 3": "00000000", "Hex Word 4": "00000012", "Callout Section": { "Callout Count": "1", "Callouts": [{ "FRU Type": "Symbolic FRU", "Priority": "Medium Priority", "Part Number": "NEXTLVL" }] } } Testing: Manually run peltool and verified out. All unit tests passed. Signed-off-by: Harisuddin Mohamed Isa <harisuddin@gmail.com> Change-Id: I124627ba785413ebda02305b7d9f95431922e714
* PEL: Add PEL D-Bus methodsMatt Spinler2020-01-271-2/+6
| | | | | | | | | | | | | | | | | | Implement the org.open_power.Logging.PEL D-Bus interface on /xyz/openbmc_project/logging. It provides the following methods: * getPEL - Return a unix FD to the PEL data based on the PEL id. * getPELFromOBMCID - Return PEL data in a vector based on the corresponding OpenBMC event log id. * hostAck - Called when the host has sent the PEL up to the OS, which is the final step in the reporting process. * hostReject - Called when the host has an issue with a PEL, either: - The host doesn't have any more room for PELs at this moment. - The PEL was malformed. Signed-off-by: Matt Spinler <spinler@us.ibm.com> Change-Id: I633ae9e26d8336973363a1a207e8fd493f7ff7d2
* PEL: Fill in host command response handlerMatt Spinler2020-01-271-2/+2
| | | | | | | | | | | | If notifying the host of a new PEL was successful, then it will modify the PEL's host transmission state to 'sent' and add it to the list of sent PELs. If there was a failure, then a timer will be started so a retry can be done. Signed-off-by: Matt Spinler <spinler@us.ibm.com> Change-Id: I77000c603a18726d4cdbb3920ca349e69198fb7f
* PEL: Add HostNotifier classMatt Spinler2020-01-271-0/+15
| | | | | | | | | | | | | This class will watch for new PELs being created, and handle sending them up to the host. This first commit for this class mostly just fills in the constructor to set up the various callbacks it will use. It is only instantiated in the Manager class if the Manager constructor used is the one that passes in the HostInterface object, to allow for configurations that don't need PELs passed up. Signed-off-by: Matt Spinler <spinler@us.ibm.com> Change-Id: I0ddcf94d047979eb78209d396c2351566c634dbe
* PEL: Print action flags into JSON alignedHarisuddin Mohamed Isa2020-01-091-1/+1
| | | | | | | | | | | | | | | | | | | "User Header": { "Section Version": "1", "Sub-section type": "0", "Log Committed by": "0x4552", "Subsystem": "System Hypervisor Firmware", "Event Scope": "Entire Platform", "Event Severity": "Informational Event", "Event Type": "Miscellaneous, Informational Only", "Action Flags": [ "Report Externally" ] } Testing: Manually run peltool and verified output Signed-off-by: Harisuddin Mohamed Isa <harisuddin@gmail.com> Change-Id: Ie8376953b5f1baa093fc0aa9564d50cd4208564e
* PEL: Add ExtendedUserHeader section classMatt Spinler2019-12-091-1/+23
| | | | | | | | | | | | | | This is a required PEL section. The section contains: * The machine type/model/SN * The server firmware version * The BMC firmware version * The 'Event Common Reference Time' (not used yet) * The symptom ID (a unique event signature) Signed-off-by: Matt Spinler <spinler@us.ibm.com> Change-Id: I223041f85965195fccf69542dbe86ce856073b36
* PEL: Validate the Action Flags fieldMatt Spinler2019-11-081-1/+11
| | | | | | | | | | | | | | | | According to the PEL spec, the Action Flags and Event Type fields in the User Header section must be in agreement with the Severity field. So, when a PEL is being created from an OpenBMC event log, check those values for correctness and fix them up if required. In addition, as those fields are optional in the message registry, this code will also just set these two fields to valid values if they were left out. The rules being followed are documented in the PEL readme. Signed-off-by: Matt Spinler <spinler@us.ibm.com> Change-Id: Iad88de5080ba79a9ff31f962ef99bfc11994b9ed
* PEL: PELTool ApplicationAatir2019-11-061-0/+1
| | | | | | | | | PELTooL application would be used to interact with PELs. This commit has the first functionality, where a PEL file is passed and all PEL sections are hexdumped in a JSON object. Signed-off-by: Aatir <aatrapps@gmail.com> Change-Id: I155d75bb58cbd14a297b094314f7fd1f271f4f37
* PEL: Add SRC PEL section classMatt Spinler2019-10-221-0/+25
| | | | | | | | | | | | | | | | | | | | | 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
* PEL: SRC callouts subsection objectMatt Spinler2019-10-221-0/+16
| | | | | | | | | | | | 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
* PEL: SRC FRU callout structureMatt Spinler2019-10-221-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | 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
* PEL: MRU callout SRC substructureMatt Spinler2019-10-221-0/+9
| | | | | | | | | | | | | | | | | | | | 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
* PEL: Power controlling enc SRC substructureMatt Spinler2019-10-221-0/+10
| | | | | | | | | | | | | | | | | | | | | 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
* PEL: FRU identity SRC substructureMatt Spinler2019-10-221-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | 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
* PEL: Represent the SRC ASCII string fieldMatt Spinler2019-10-221-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* PEL: User Data classAatir Manzur2019-10-091-0/+11
| | | | | | | | | | | 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
* PEL: Flatten PEL from objectsMatt Spinler2019-10-091-0/+10
| | | | | | | | | | | | | | | | | | | 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
* PEL: Create object for every sectionMatt Spinler2019-10-091-0/+4
| | | | | | | | | | | | | | 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
* PEL: Add a Generic section objectMatt Spinler2019-10-091-0/+10
| | | | | | | | | | | | | | | 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
* PEL: OpenBMC event log sev to PEL sev helperMatt Spinler2019-10-091-0/+10
| | | | | | | | | | | | | 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
* PEL: Find an entry in the message registry JSONMatt Spinler2019-10-091-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* PEL: Support for going between PELs & registryMatt Spinler2019-10-011-0/+9
| | | | | | | | | | | | | | | | | | | 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
* PEL: Add FailingMTMS PEL section classMatt Spinler2019-09-271-0/+10
| | | | | | | | | | | | | 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
* PEL: Interface to collect system dataMatt Spinler2019-09-271-0/+1
| | | | | | | | | | | | | | | | | 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
* PEL: MTMS class to handle the type-model and SNMatt Spinler2019-09-271-1/+10
| | | | | | | | | | | | | | | | 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
* PEL: Add repository to save PELsMatt Spinler2019-08-051-0/+23
| | | | | | | | | | | | | | 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
* PEL: Add PEL classMatt Spinler2019-08-051-2/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* PEL: Add function to generate unique PEL IDsMatt Spinler2019-07-261-0/+10
| | | | | | | | | | | | 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
* PEL: Add UserHeader classMatt Spinler2019-07-261-2/+13
| | | | | | | | | | | | | The second section in a PEL is always the 'User Header' section. This commit adds a class to represent that. Right now, the only constructor available is filling in its data fields from a PEL stream. Several of the fields in this section have predefined values that are defined by the PEL specification. Defining any constants or enums for those will be left to future commits where they will actually be used. Signed-off-by: Matt Spinler <spinler@us.ibm.com> Change-Id: I8b5f856a4284d44c31b04e98a664f20cd8fa0cb6
* PEL: Add PrivateHeader classMatt Spinler2019-07-261-1/+15
| | | | | | | | | | | | | The first section in a PEL is always the 'Private Header' section. This commit adds a class to represent that. Right now, the only constructor available is filling in its data fields from a PEL stream. The Section base class, which will be the base class of all PEL sections, is also being introduced here. It contains the section header structure, and a valid flag that derived classes can use. Signed-off-by: Matt Spinler <spinler@us.ibm.com> Change-Id: Ia5806017155fe1ef29ea57bf8ab202ff861bde2e
* PEL: Add PEL section header structureMatt Spinler2019-07-261-1/+9
| | | | | | | | | | A PEL is made up of sections, and every section has an 8B section header. This commit adds a SectionHeader structure that will represent that header. It will then be included in all upcoming PEL sections. Signed-off-by: Matt Spinler <spinler@us.ibm.com> Change-Id: Ia5356560f49707e21aebca28f4a0b525aa24158d
* PEL: Add BCD time helpers for PELsMatt Spinler2019-07-261-1/+11
| | | | | | | | | | | | | | | | | | | | | | | A PEL stores time in BCD, with a byte each for: * year MSB * year LSB * month * day * hour * minutes * seconds * hundredths This commit adds a structure to represent this, and functions to: * Create a BCD structure from a std::chrono::time_point * Convert any number to BCD * Write the BCD structure into a Stream * Extract a BCD structure from a Stream Refresher: The BCD value of 32 is 0x32. Signed-off-by: Matt Spinler <spinler@us.ibm.com> Change-Id: I09ea4098f3a3981931f595d11fb63aff31d9fb0d
* PEL: Add Stream class to manipulate PEL dataMatt Spinler2019-07-261-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This stream inserts data into and extracts data from the vector<uint8_t> that it is given in its contructor. That vector is how PEL data is stored. This object takes care of the endian conversion for fields that require it, as PEL data is big endian. On writes, it will expand the vector if necessary. An exception will be thrown an invalid access is attempted, such as trying to extract a value when at the end of the data. It provides >> and << operators for common data types, as well as read()/write() functions when using other types. Example: std::vector<uint8_t> data; Stream stream{data}; uin32_t value = 0x12345678; stream << value; stream.offset(0); uint32_t newValue; stream >> newValue; assert(value == newValue); uint8_t buf[3000] = {0}; stream.write(buf, 3000); Signed-off-by: Matt Spinler <spinler@us.ibm.com> Change-Id: I8dc5566371749b45a260389a564836433323eef8
* PEL: Add class to wrap AdditionalDataMatt Spinler2019-07-261-0/+10
The AdditionalData property on the xyz.openbmc_project.Logging.Entry interface is a vector of strings of the form: "KEY=VALUE". The PEL processing code will be interested in those keys and values, and this class adds a way to get at those values based on a key without having to do string parsing each time. It returns an std::optional<std::string> value, and if the key isn't found, then the std::optional value will be empty. For Example: AdditionalData ad{additionalDataPropertyValue}; // Get the value for the FOO key std::optional<std::string> val = ad.getValue("FOO"); if (val) std::cout << (*val).size(); Signed-off-by: Matt Spinler <spinler@us.ibm.com> Change-Id: I6ba458840278784b1cc6a0ed88a7fece8794df7d
OpenPOWER on IntegriCloud