Conversation
chrysh
force-pushed
the
pldm-ipc-server
branch
from
September 23, 2026 14:55
2a974fb to
972c451
Compare
Defines the binary protocol the orchestrator uses to talk to the PLDM Firmware Device over IPC. Twelve operations covering the full update lifecycle: offer accept/reject, verify/apply grant/deny, activation, SVN commit, cancel ack, and status query. Wire format: fixed 8-byte headers for both request and response, with manual byte encoding (no zerocopy dep) for no_std compatibility. The doc's response diagram adds to 6 bytes; the prose says "Fixed 8-byte header," so we pad 2 reserved bytes to match the stated intent. The doc field `gen` is renamed to `generation` because `gen` is a reserved keyword in Rust 2024 edition. All four Deny* ops carry a DenyReason byte for uniformity (the doc pins DenySvnCommit to PolicyViolation, but sending the reason on the wire keeps the decode path identical to the other denials). The FdStatus enum encodes the FD's current condition as a QueryStatus response payload, covering all DSP0267 states plus pending decisions. OfferPending carries target, total, transfer mode, and the SVN delayed flag from the UA's UpdateComponent request, so the orchestrator can validate against the floor. The Transport trait is the seam the client crate will be generic over, split into start/poll/cancel rather than one blocking round-trip: the orchestrator client runs in the event loop, which must not block. In production it is backed by util/ipc's AsyncTransaction; host tests use LoopbackTransport. Host-buildable with no kernel dependencies. All encode/decode paths have roundtrip tests. Assisted-by: Claude Code
The FD side of the IPC channel. dispatch() decodes the orchestrator's request header, matches on PldmOp, calls the corresponding FdHandler trait method, and encodes the response. FdHandler has one method per opcode so the implementation never touches wire bytes. LoopbackTransport implements pldm_ipc_api::Transport by calling dispatch directly in-process. Dispatch runs inside start(), so the response is ready on the first poll(); the split-phase shape is kept so client code written against a real channel runs unchanged here. The loopback tests show a multi-step sequence (accept offer, then query status shows ReadyXfer), proving the wire format, dispatch, and status encoding work together, plus the state rules: start while pending, poll with nothing in flight, cancel, and a short response buffer. Same pattern as services/i2c/server: dispatch generic over a trait, loopback transport in the server crate, host-buildable with no kernel dependencies. Assisted-by: Claude Code
chrysh
force-pushed
the
pldm-ipc-server
branch
from
September 25, 2026 10:28
972c451 to
bfbd8ef
Compare
This was referenced Sep 25, 2026
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The FD side of the IPC channel. dispatch() decodes the orchestrator's
request, matches on PldmOp, calls the corresponding FdHandler method,
and encodes the response. LoopbackTransport calls dispatch directly
in-process so the same encode/decode paths get exercised with no kernel.
Same pattern as services/i2c/server: dispatch generic over a trait,
loopback transport in the server crate, host-buildable.
#479 has merged. Review the last commit only; below it is #483, the API
crate this depends on.
Transport is split-phase (start/poll/cancel) rather than one blocking
round-trip, because the orchestrator client runs in the event loop and
must not block. In production it is backed by util/ipc's
AsyncTransaction. LoopbackTransport has the response ready on the first
poll, so Ok(None) handling is untested here; the client PR needs a
not-ready-then-ready stub to cover it.
FdHandler is the IPC dispatch seam on the FD side (one method per
opcode, never touches wire bytes). FdOps in pldm-lib is the callback
trait for actual download/verify/apply operations, arriving later.
Assisted-by: Claude Code