commit | c53c6fe9b0534ab5bba769a1d404469ebb05f772 | [log] [tgz] |
---|---|---|
author | Andrew Jeffery <andrew@codeconstruct.com.au> | Mon Aug 11 07:44:38 2025 +0000 |
committer | Andrew Jeffery <andrew@codeconstruct.com.au> | Tue Aug 19 11:08:54 2025 +0930 |
tree | c285ccb36c426275119e9e16163dcb42566f8c0f | |
parent | fcc15b86384d82ff28a6e1fc6f120f6bbdfb653e [diff] |
dsp: firmware_update: Run-time state machine for package parsing Encoding the necessary sequence of calls with an approximation of linear types is hampered by DSP0267's introduction of entirely new sections into the package format across revisions. The existing design enforced a sequence that precluded _not_ calling the decoder for downstream device records in the case of pinning to format revision 1. The choice had the further effect of stunting the API to future expansion of the spec. Switch from linear types to tracking parse state at runtime based on the provided pin and the extracted package header. The state machine implementation is modeled on the TLA+ specification below, with NR_FORMATS set to 4 in the model: ```tla ---- MODULE pldm_package_parser ---- EXTENDS Integers, Sequences \* pin and format have non-deterministic init, but are then constant VARIABLE state, pin, format vars == << state, pin, format >> States == { "Init", "Header", "FirmwareDevices", "DownstreamDevices", "ComponentImageInfos", "Complete", "Unsupported", "Error" } Formats == 1..4 DecodeHeader == /\ state = "Init" /\ state' = IF format <= pin THEN "Header" ELSE "Unsupported" /\ UNCHANGED << pin, format >> DecodeFirmwareDevices == /\ state = "Header" /\ state' = "FirmwareDevices" /\ UNCHANGED << pin, format >> DecodeDownstreamDevices == /\ state = "FirmwareDevices" /\ state' = IF pin = 1 THEN "Error" ELSE "DownstreamDevices" /\ UNCHANGED << pin, format >> DecodeComponentImageInfos == /\ \/ /\ state = "FirmwareDevices" /\ pin = 1 \/ /\ state = "DownstreamDevices" /\ pin \in ( Formats \ { 1 } ) /\ state' = "Complete" /\ UNCHANGED << pin, format >> Done == state \in { "Complete", "Unsupported", "Error" } /\ UNCHANGED vars Init == /\ state = "Init" /\ pin \in Formats /\ format \in Formats Next == \/ DecodeHeader \/ DecodeFirmwareDevices \/ DecodeDownstreamDevices \/ DecodeComponentImageInfos \/ Done Spec == Init /\ [][Next]_vars /\ WF_state(Next) TypeInvariant == /\ state \in States /\ pin \in Formats /\ format \in Formats Safety == /\ TypeInvariant /\ state \in States \ { "Init", "Unsupported" } => format <= pin Liveness == /\ [][(state \in { "Complete", "Unsupported", "Error" } => UNCHANGED state)]_vars /\ [][UNCHANGED <<pin, format>>]_vars ==== ``` For an introduction to TLA+ see https://www.learntla.com/ Note that the implemented state machine does not exactly replicate that specified in the model. Specifically: - No "Unsupported" state is defined. Instead, the APIs return -ENOTSUP - No "Error" state is defined. Instead, the APIs return -EPROTO It is expected that callers perform appropriate error handling. Change-Id: Id8780c1f5f130b77e6eea2519b5d5734aa79040e Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>
This is a library which deals with the encoding and decoding of PLDM messages. It should be possible to use this library by projects other than OpenBMC, and hence certain constraints apply to it:
Source files are named according to the PLDM Type, for eg base.[h/c], fru.[h/c], etc.
Given a PLDM command "foo", the library will provide the following API: For the Requester function:
encode_foo_req() - encode a foo request decode_foo_resp() - decode a response to foo
For the Responder function:
decode_foo_req() - decode a foo request encode_foo_resp() - encode a response to foo
The library also provides API to pack and unpack PLDM headers.
libpldm
is configured and built using meson
. Python's pip
or pipx
can be used to install a recent version on your machine:
pipx install meson
Once meson
is installed:
meson setup build && meson compile -C build
meson test -C build
libpldm
Components of the library ABI[^1] (loosely, functions) are separated into three categories:
[^1]: "library API + compiler ABI = library ABI"
Applications depending on libpldm
should aim to only use functions from the stable category. However, this may not always be possible. What to do when required functions fall into the deprecated or testing categories is discussed in CONTRIBUTING.
libpldm is maintained with the expectation that users move between successive releases when upgrading. This constraint allows the library to reintroduce types and functions of the same name in subsequent releases in the knowledge that there are no remaining users of previous definitions. While strategies are employed to avoid breaking existing APIs unnecessarily, the library is still to reach maturity, and we must allow for improvements to be made in the design.