pldm: Add the pldm-notify IPC channel (PoC) - #457
Draft
chrysh wants to merge 4 commits into
Draft
Conversation
The test drove the orchestrator's UpdateRequestLatch, which put both orchestrator crates in a PLDM test's deps. A local counting sink asserts the same thing: an accepted RequestUpdate notifies once, a rejected one does not, and nothing later does. Absolute counts rather than a drain, so each assertion says how many notifications have happened at that point in the session.
chrysh
force-pushed
the
pldm-update-request-ipc
branch
from
September 3, 2026 17:28
183121d to
5333788
Compare
Wire protocol for the PLDM-to-orchestrator notification channel. PLDM initiates, the orchestrator handles. One opcode today (UpdateRequested), two responses (Accepted, Rejected) so the orchestrator can veto before the transfer starts. Header is [op/code:1B][len:1B][reserved:2B] each way. Both enums are non_exhaustive because the two sides are separate processes that may be built from different revisions. Builds and tests on the host, no kernel dependency. Assisted-by: Claude
dispatch() decodes one notification from the PLDM service, encodes an accept or reject based on the caller's verdict, and returns the notification in orchestrator-side vocabulary. The caller decides the verdict; the adapter translates both ways. Returns Notification, not a state-machine Event: the notification arrives before the FD has accepted, so there is nothing to authenticate yet. The state machine hears about the update later, at complete-time on the intake seam. Depends on the wire crate only, not on orchestrator-sm. Assisted-by: Claude
chrysh
force-pushed
the
pldm-update-request-ipc
branch
2 times, most recently
from
September 3, 2026 18:12
2d820a1 to
3f2628a
Compare
Two pw_kernel processes on a real channel under QEMU. The PLDM side sends Request::UpdateRequested via channel_transact, the orchestrator side waits, reads, runs dispatch (always accepting for the PoC), and answers. The PLDM side checks for Response::Accepted and shuts down with PASS. Asserts Notification::UpdateRequested on the handler side, consistent with the adapter returning orchestrator-side vocabulary rather than a state-machine event. Assisted-by: Claude
chrysh
force-pushed
the
pldm-update-request-ipc
branch
from
September 3, 2026 18:14
3f2628a to
b091e19
Compare
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.
Summary
services/pldm/notify-api) for PLDM-to-orchestrator notifications. One opcode today (UpdateRequested), two responses (Accepted,Rejected) so the orchestrator can veto before the FD accepts the UA's request.services/orchestrator/adapters/pldm) translates wire vocabulary to orchestrator-sideNotificationand encodes the caller's accept/reject verdict.target/ast10x0/tests/pldm_notify) wires two pw_kernel processes on a real channel, always accepting for the PoC.firmware_update_host.rstracks how many times the FD fires a notification callback.Header is
[op/code:1B][len:1B][reserved:2B]each way, 4 bytes per frame. Both enums are#[non_exhaustive](the two sides are separate processes). The opcode space is flat, not update-specific.The PoC always accepts. Veto logic, starvation mitigation, and PLDM FD integration come later.
Test plan
bazel test //services/pldm/notify-api:pldm_notify_api_testbazel test //services/orchestrator/adapters/pldm:orchestrator_pldm_adapter_testbazel test //services/pldm:firmware_update_host_testbazel test --config=virt_ast10x0 //target/ast10x0/tests/pldm_notify:pldm_notify_qemu_testAssisted-by: Claude