clang-format: re-format for clang-18

clang-format-18 isn't compatible with the clang-format-17 output, so we
need to reformat the code with the latest version. The way clang-18
handles lambda forma

clang-format: re-format for clang-18

clang-format-18 isn't compatible with the clang-format-17 output, so we
need to reformat the code with the latest version. The way clang-18
handles lambda formatting also changed, so we have made changes to the
organization default style format to better handle lambda formatting.

See I5e08687e696dd240402a2780158664b7113def0e for updated style.
See Iea0776aaa7edd483fa395e23de25ebf5a6288f71 for clang-18 enablement.

Change-Id: I09e19a126d456dc184fd70e82d4e4e4217fa8ee7
Signed-off-by: Patrick Williams <patrick@stwcx.xyz>

show more ...

bmc: version: Skip version if it does not exist in the config

Change-Id: I1ea876183ff12dab8fc479c45f7b3a9eba50b56f
Signed-off-by: Willy Tu <wltu@google.com>

version-handler: Refactor handler construction

Instead of requiring callers to build maps and info blobs, take the
minimal required amount of information about the blob configuration and
build requi

version-handler: Refactor handler construction

Instead of requiring callers to build maps and info blobs, take the
minimal required amount of information about the blob configuration and
build required datastructures internally.

This reduces the amount of code, and nearly eliminates all of the
untested code in main.cpp.

Change-Id: Iaa398eb404814e9263e6707b71b38a9831d96697
Signed-off-by: William A. Kennington III <wak@google.com>

show more ...

version_handlers_builder: Use string references

Change-Id: Iefa4b09c2952eb5f6e7da4509c1a7a39dead9ed7
Signed-off-by: William A. Kennington III <wak@google.com>

version-handler: implement json parser

version-handler adds the following capability

- ipmi-flash blobs can add a "version" along with the required
nested properties. This enables versioning suppor

version-handler: implement json parser

version-handler adds the following capability

- ipmi-flash blobs can add a "version" along with the required
nested properties. This enables versioning support for that
flash blob.
For instance,
{
"blob" : "/flash/sink_seq",
"version":{ //now a /version/sink_seq blob will appear
"handler": {
"type: : "file", //only file type is supported
"path" : "/tmp/version_info" // file contents
// contain textual version.
// Content returned on read
},
"actions":{
"open" : { //on open launch a systemd target
"type" : "systemd",
"unit" : "version.target"
}
}
}
}

In the above example (pretend that the rest of the required
firmware-handler fields are present) firmware handler will create the
normal ipmi-flash blobs needed for updating firmware.
The addition of the "version" section activates the version-handler
which exposes a blob named /version/sink_seq.

Opening /version/sink_seq will kick off the action specified. In this
case the systemd target version.target will be launched. This service
should retrieve the version information and then place the contents in
the file specified by handler - path (/tmp/version_info).

The user at this point can poll (stat) the blob until the meta-data
indicates that read data is ready.

A read can be issued for /version/sink_seq. What is returned will be the
contents of /tmp/version_info.

Signed-off-by: Jason Ling <jasonling@google.com>
Change-Id: I7cc7bec2e08b013c6b77f8dfd2a502272ad2d3bd

show more ...