Software Bus: provide a no_std shared-memory/ipc_service transport backend behind the stream<T> seam (inter-core)

[avrabe]

Software Bus needs a no_std shared-memory transport backend behind the stream<T> seam (inter-core)

The relay-software-bus WIT (wit/interfaces/relay-software-bus/bus.wit) documents the intent stream<T> → Gale ring_buf, future<T> → Gale event — i.e. the typed-stream interface is transport-neutral and the backend is chosen by the host/linker. But in the current tree the only Software Bus implementation is host/relay-sb/src/core.rs, which is std-only (Vec/VecDeque, in-process) — there is no no_std shared-memory / Zephyr ipc_service / CAN backend in source (confirmed by code search).

jess needs exactly that backend for the Pixhawk 6X-RT: an inter-core (M7 ↔ M4) shared-memory ring + mailbox-IRQ transport behind the stream seam (REQ-PIX-007/008, DD-009). The natural shape per the bus.wit comment is a no_std/no_alloc SPSC ring on a Gale ring_buf (or a Zephyr ipc_service/ICMsg backend), with the RT1176 non-cacheable-shared-region + cache-coherency handling.

The ask: is a no_std shared-memory Software Bus backend in scope for relay, or should it live in gale (cross-ref gale#63, which already covers the gale executable substrate)? Either way jess would like to co-design/contribute the backend so the stream<T> seam has a real embedded transport, and the same WIT contract can be fused (same core, meld) or streamed (cross core) as a deployment choice. If relay owns the seam and gale owns the ring, a thin agreed interface between them is the thing to pin.

Grounded in the relay-comms deep-dive (jess iter#18). Happy to bring a spar/AADL model of the transport binding.

[avrabe]

Triaged: real feature, connects to the P3/stream arc + Gale.

Confirmed: bus.wit documents stream<T> → Gale ring_buf, future<T> → Gale event (transport-neutral seam), but the only impl is host/relay-sb/src/core.rs (std-only Vec/VecDeque, in-process). No no_std shared-memory / Zephyr ipc_service / CAN backend exists.

This is the embedded data-plane half of the P3 story: the v1.57+ arc authors components as P3 stream<T> transformers (RFC #46: Meld lowers them to core modules at build time), and this issue is the runtime backend those lowered streams ride on inter-core. So it's downstream of the streamification arc and the Gale ring_buf/event primitives. Scope: a no_std Software Bus backend behind the stream<T> seam, backed by a shared-memory region (M7↔M4) / ipc_service (Zephyr) with the bounded-buffer discipline BackpressureSafety.lean already proves (output ≤ input×K → buffer sizing). Pairs with #176 (relay-sec E2E over the same inter-core links). Kept open, assignable; candidate after the P3 streamification lands a real stream channel (ties to #7 too). Genuine engineering — not closing.

[avrabe]

Heads-up on what this carrier transports (jess DD-009). jess decided to reuse relay's comms wholesale: the carrier requested here moves relay-ccsds Space Packets wrapped by relay-sec.wrap (header‖payload‖Ascon-tag) — i.e. falcon's exact C2 stack (CCSDS + relay-sec), just pointed at a shared-memory inter-core link instead of the ground radio. So this issue is purely the no_std shared-memory ring/mailbox carrier; relay-ccsds + relay-sec are reused unchanged (relay#176 withdrawn — wrap is already byte-agnostic). Co-design point with gale#63 (the Gale ring_buf is the natural backend). Cross-ref: jess DD-009.

[avrabe]

Relay-side answer to the ownership question: relay owns the seam, Gale owns the ring — and the seam is the net-new relay piece to pin.

Grounded in the source, not a preference:

• The WIT seam already declares this split. wit/interfaces/relay-software-bus/bus.wit documents "On embedded (Synth → ARM → Gale): stream<T> → Gale ring_buf (RB01-RB08 verified), future<T> → Gale event", with reader handles "backed by Gale ring_buf on embedded." So the intended architecture is already relay = the typed stream<T> contract, Gale = the verified ring. gale#63 is the right home for the ring substrate.
• What's missing is the Rust seam, not the design. host/relay-sb/src/core.rs is today a single std-only impl (Vec/VecDeque, in-process) with no backend trait — there's no boundary a no_std shared-memory ring can plug into. So the "thin agreed interface to pin" you asked about doesn't exist as Rust yet.

Proposal (and an offer): relay lands the missing piece — a no_std/no_alloc backend trait under the bus seam (the stream<T>/future<T> → pluggable-transport boundary), with the existing relay-sb as the std backend and a clear contract (SPSC, bounded, buffer-exhausted/backpressure already in sb-error) that a Gale ring_buf or a Zephyr ipc_service/ICMsg backend implements. That trait is the thin interface; gale#63 fills it with the verified ring; jess co-designs the embedded backend against it. This keeps the carrier purely transport (per your DD-009 note) and keeps relay-ccsds + relay-sec reused unchanged.

I've scoped the relay-side seam as SWREQ-SB-P01 (candidate v1.60); the ring impl stays Gale/jess. Will bring a concrete trait sketch for co-design.

Related, shipping now: relay v1.59 (PR #179, merged) hardens the other half of what this carrier transports — it proves (Kani SEC-K15, cross-channel isolation for all SPI pairs) and documents that relay-sec.wrap is transport-agnostic, so the same E2E layer is sound over a shared-memory link as over the radio. That's an additional release you can build the carrier on top of.