[Japabu]

Draft, stacked on #1121 (base ipc-messages). It needs a keep-or-drop decision before more work goes into it.

What it does

SYS_MESSAGE_CALL is SYS_MESSAGE_SEND followed by a blocking SYS_MESSAGE_RECV on the same connection, in one syscall.

• A refused send answers as a send does, with nothing sent. Once the request is queued, the receive answers as a receive does, into the same two windows IPC phase 2: a connection carries whole messages #1121's receive takes.
• The request carries no handles. An error could come from either half, so a caller could not know whether its handles had moved.
• Connection::call takes the answer straight into the caller's buffer, as recv_into does.
• Consumers: the file server's client (toyos::fs's request and reply) and osbench's ipc.reqrep rows. messages_are_whole checks that a call takes its peer's answer, with the answer's handle, split across both windows.

Why it may not earn its place

The call was meant to tell the scheduler that its caller parks next, so the callee could run where the caller leaves (WakeCause::parks_next).

• sched: a wake its poster parks or exits behind runs where it was posted #1111 has since dropped that field and its hand-off (e938fe3e5): no caller set it. sched: a woken partner follows its waker's LLC #1129's waker-LLC affinity carries the waker on every wake instead.
• This branch therefore no longer passes any hint. The call is a fused send and receive and saves one syscall entry and exit per round trip.
• IPC phase 2: a connection carries whole messages #1121's first round measured the earlier version with the hint, on the T14 and the AMD bench. It saved about that one syscall on ipc.reqrep.8 and nothing on the fs rows. The profile showed the hint never reached the file server, which waits through poll delivery.
• Decision wanted: keep a syscall number for one syscall's saving per round trip, or close this PR and delete the branch. If it is kept, the next step is an A/B against IPC phase 2: a connection carries whole messages #1121 on ipc.reqrep.* and the fs rows, with the rule stated before the run.

Checks at 6ffcb2402

• cargo run -- --ci host: exit 0, 107/107. cargo run -- --build-only: exit 0.
• QEMU x86-64, remote runner, one --debug testcases boot at 6ffcb2402: exit 0. messages_are_whole (with the call's split answer) and connect_before_serve exited 0. Every toyos::fs request in that boot goes through the call.
• An earlier version still set parks_next and failed to compile against IPC phase 2: a connection carries whole messages #1121's tree. That is why the hint is out.
• Evidence: https://github.com/ToyOSOrg/evidence/tree/05eef35125bb758d9880f5e21d48b1e40d09b193/ipc-call/6ffcb2402

🤖 Generated with Claude Code

[Japabu]

Closing this, by the orchestrator's decision.

#1111 dropped WakeCause::parks_next (e938fe3e5), so all the call has left is one syscall entry and exit per round trip. #1121's first round measured the call while it still carried that hint, on the T14 and the AMD bench:

• it saved about one syscall on ipc.reqrep.8;
• it saved nothing on the fs rows;
• parks_next never reached the file server, which waits through poll delivery.

That saving does not earn a permanent syscall number and a second send path ("Code is liability").

The branch ipc-call stays at 6ffcb2402 for the record. Evidence for this head: https://github.com/ToyOSOrg/evidence/tree/05eef35125bb758d9880f5e21d48b1e40d09b193/ipc-call/6ffcb2402