util/service: Add the IPC service seam traits - #485
Merged
chrysh merged 1 commit intoSep 25, 2026
Merged
Conversation
Collaborator
|
will merge after #479 |
rusty1968
approved these changes
Sep 23, 2026
Collaborator
|
Please review and check if this is still required. |
chrysh
force-pushed
the
util-service-traits
branch
2 times, most recently
from
September 25, 2026 11:57
77d97dc to
3e5d386
Compare
This was referenced Sep 25, 2026
Every IPC service so far has defined its own copy of the same three seams: a transport trait, a server dispatch function, and the error type between them. i2c and pldm each carry one, and they have already drifted apart. This crate holds them once so a service defines its wire format and nothing else. Transport blocks until the response arrives; AsyncTransport splits the round-trip so an event-loop caller never blocks. A type implements whichever it can serve, or both. Dispatch is the server end, one request frame in, one response frame out. It returns Result rather than a byte count with 0 meaning failure: a service that merely failed an operation encodes that into the response frame and still returns Ok, and the one case with nothing to send back is a response buffer too small to hold even an error frame. Traits only, no implementations and no migrations, so there is nothing to unit test here. The generic loopback and the kernel channel transport follow, then i2c and pldm move over. Assisted-by: Claude Code
chrysh
force-pushed
the
util-service-traits
branch
from
September 25, 2026 13:32
3e5d386 to
11bc272
Compare
chrysh
marked this pull request as ready for review
September 25, 2026 13:41
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
2 participants
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 seams every IPC service is built from, held once instead of copied
per service. i2c and pldm each carry their own transport trait, dispatch
function and error type today, and the two have already drifted.
Transport blocks until the response arrives; AsyncTransport splits the
round-trip so an event-loop caller never blocks. A type implements
whichever it can serve, or both. Dispatch is the server end: one request
frame in, one response frame out.
Transport takes no deadline. i2c's seam has none today (IpcTransport
hardcodes Instant::MAX), and a host-buildable crate cannot name
userspace::time::Instant. Timeouts are the caller's concern; a caller
that cannot block uses AsyncTransport.
#479 has merged, so this is one commit on ocp-global-demo-wip with
nothing stacked below it.
Not in this PR, and no longer hypothetical: the generic Loopback over
Dispatch is #498, the kernel AsyncChannelTransport is #497, and the
pldm migration onto this seam is #499. i2c has not moved yet. mctp has no transport seam today and spdm, storage and
telemetry are not IPC-shaped, so none of them are in scope.
Assisted-by: Claude Code