Trait Connect 

pub trait Connect: TransportError {
    type Params;

    // Required method
    fn connect(
        &mut self,
        params: Self::Params,
    ) -> impl Future<Output = Result<(), Self::Error>> + MaybeSend;
}

A transport that must rendezvous with its remote peer before carrying traffic.

The trait covers exactly one thing: waiting until the far side of a link is ready. Implement it when a peer must agree — on a memory layout, a protocol version, an MTU — before the first message can be sent. The defining property is that there is another party, and that the operation can fail because that party never showed up or disagreed. That is why connect is async: the wait is genuine, not incidental.

Contract

• Call connect once, after construction and before any send or recv, and before splitting a full-duplex transport into halves — the handshake is a property of the whole link, not of one direction.
• Implementations are side-asymmetric where the protocol is. The two ends of one link may run different code, selected by the transport’s type (typically its Side) rather than by a runtime branch in the caller. Generated bring-up code can then emit one connect call for both sides.
• connect carries no timeout. A peer that never answers parks the caller forever, so callers needing bounded bring-up impose their own deadline (tokio::time::timeout, embassy_time::with_timeout).
• connect is safe. A transport whose construction is unsafe (raw shared memory, say) discharges that obligation in its constructor; connect relies on the invariant already established there.

What does not belong here

Local bring-up is not a rendezvous, and routing it through this trait would make plain register writes pretend to await something.

• Peripherals. Enabling a clock, muxing pins and programming registers has no peer and no protocol. Its real complexity is the ordering graph between peripherals, which a per-object method cannot express; in this workspace that sequencing is emitted by consortium-cfg into the generated init(). Peripheral drivers keep the ecosystem convention instead: constructor plus config struct, with typestate where readiness is worth encoding in the type.
• Doorbells. They have local setup (unmasking an interrupt, binding to the Linux UIO fan-out) but no handshake, which is why that stays plain inherent API (bind_notifier / bind_service).

Waiting on someone else is Connect; configuring your own silicon is a constructor.

Example

The uniform shape lets bring-up code drive any link the same way:

async fn bring_up<T: Connect>(transport: &mut T, params: T::Params) -> Result<(), T::Error> {
    transport.connect(params).await
}

Required Associated Types

type Params

Handshake inputs that are negotiated rather than owned by the transport.

Anything that identifies the link — channel ids, the doorbell, the region base — belongs in the constructor. What lands here is what the two ends must agree on, and whose agreed value the transport learns only by completing the handshake (for shared memory: the channel count and the proposed MTU). Transports with nothing to negotiate use ().

Required Methods

fn connect( &mut self, params: Self::Params, ) -> impl Future<Output = Result<(), Self::Error>> + MaybeSend

Run the readiness handshake with the remote end.

Resolves once the peer is ready; the transport may record what the handshake settled (a negotiated MTU, say) before returning. Call once, before any traffic and before splitting into halves.

Dyn Compatibility

This trait is not dyn compatible.

In older versions of Rust, dyn compatibility was called "object safety".

Implementors