Skip to content

docs: PLDM/orchestrator IPC design - #29

Closed
chrysh wants to merge 1 commit into
mainfrom
worktree-docs-pldm-ipc
Closed

chrysh wants to merge 1 commit into
mainfrom
worktree-docs-pldm-ipc

Conversation

@chrysh

@chrysh chrysh commented Sep 7, 2026

Copy link
Copy Markdown
Collaborator

Summary

  • PLDM/orchestrator IPC design as an interactive sequence diagram
  • Two kernel channels (notify + intake), both initiated by PLDM
  • Firmware bytes stay out of IPC (direct to flash)
  • Verified: USER signal latches (level-triggered), MCTP server buffers 4 messages, poll_stage bounded by flash erase time

Rendered diagram: https://claude.ai/code/artifact/02aaee3c-a2fa-4d7e-8753-c84a0331a39d

Open questions in the diagram:

  • Activation gating: add Activate(5) to the wire, or auto-activate after staging?
  • BlockingFlash erase (10-100ms) inside poll_stage vs async flash seam

Test plan

  • Review rendered diagram via artifact link
  • Comment on open design questions

Assisted-by: Claude

Sequence diagram covering the two-channel IPC architecture between the
PLDM FirmwareDevice service and the orchestrator. Covers the notify
channel (pre-transfer veto), intake channel (offer/write/complete/poll),
async effect chain with poll_stage, USER signal nudge, and FD-initiated
PLDM commands.

Includes verified findings: USER signal is level-triggered (no lost
wakeups), MCTP server buffers 4 messages independently while PLDM is in
a transact, and poll_stage worst case is bounded by flash erase time.

Assisted-by: Claude
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: Done

Development

Successfully merging this pull request may close these issues.

1 participant