Trait BoardEntry 

pub trait BoardEntry: Board {
    // Required method
    fn run<F, E>(setup: F) -> Result<(), E>
       where F: FnOnce(&mut RuntimeCtx<'_>) -> Result<(), E>,
             E: Debug;

    // Provided methods
    fn run_with_deploy<F, E>(_deploy: &DeployOverlay, setup: F) -> Result<(), E>
       where F: FnOnce(&mut RuntimeCtx<'_>) -> Result<(), E>,
             E: Debug { ... }
    fn run_with_deploy_sized<F, E>(
        deploy: &DeployOverlay,
        _max_cbs: usize,
        _max_sched_contexts: usize,
        setup: F,
    ) -> Result<(), E>
       where F: FnOnce(&mut RuntimeCtx<'_>) -> Result<(), E>,
             E: Debug { ... }
    fn setup_transport(_deploy: &DeployOverlay) { ... }
}

Per-board boot driver.

Implementations live in the family driver crates (nros-board-posix, nros-board-freertos, …). Per-board crates (nros-board-mps2-an385-freertos, …) plug the family.

Required Methods

fn run<F, E>(setup: F) -> Result<(), E>

where F: FnOnce(&mut RuntimeCtx<'_>) -> Result<(), E>, E: Debug,

Drive the full boot → user-closure → exit flow.

setup receives a &mut RuntimeCtx with overlay knobs from the launch file / CLI args. Returning Err from setup makes run route to super::BoardExit::exit_failure; Ok proceeds to executor spin + clean exit.

Returns Result, not !. The legacy nros-board-common::board_init::BoardEntry::run diverged; 212.N keeps the option to return so unit tests can drive it in a hosted process without exit() killing the test harness. Production boards still call exit_* from inside run’s body after spin returns.

Provided Methods

fn run_with_deploy<F, E>(_deploy: &DeployOverlay, setup: F) -> Result<(), E>

where F: FnOnce(&mut RuntimeCtx<'_>) -> Result<(), E>, E: Debug,

Boot like run but apply a deploy-metadata overlay to the board’s boot config first (issue #48 cause 1).

The default body ignores deploy and forwards to run; boards that compile a network/locator config (the FreeRTOS / bare-metal firmware boards) override it to overlay the supplied fields onto their Config::default(). nros::main!() calls this (not run) for target_os = "none" OwnedSpin targets so the [package.metadata.nros.deploy.<board>] block stops being inert.

fn run_with_deploy_sized<F, E>( deploy: &DeployOverlay, _max_cbs: usize, _max_sched_contexts: usize, setup: F, ) -> Result<(), E>

where F: FnOnce(&mut RuntimeCtx<'_>) -> Result<(), E>, E: Debug,

phase-271 (issue #110) — boot like run_with_deploy but size the executor’s callback table + arena to the entry’s OWN declared topology (max_cbs / max_sched_contexts, from the entry’s [package.metadata.nros.entry]), instead of the workspace-global NROS_EXECUTOR_MAX_CBS build const.

Sizes are plain usizes (not nros::ExecutorSizing) because nros-platform sits below nros; the hosted board converts them. A max_sched_contexts of 0 means “use the build default”. The default body IGNORES the sizing and forwards to run_with_deploy, so every board except the hosted (posix) one — which opens via Executor::open and could grow its arena — is byte-identical; the posix board overrides this to Executor::open_sized. nros::main!() emits this (instead of run_with_deploy) only when the entry declares max_callbacks.

fn setup_transport(_deploy: &DeployOverlay)

Custom-transport install seam. Install a board-specific transport selected by deploy.transport, BEFORE the linked RMW registers (phase-244.D1).

nros::main!() always emits a setup_transport call (gated on target_os = "none") immediately before __register_linked_rmw(), so that the vtable is in place before the XRCE backend registers — the ordering set_custom_transport_ops requires.

This method is intentionally kept — it is not dead code. The default no-op is correct for every board whose transport is registered automatically (Zenoh, native sockets, etc.). The only current override is nros-board-mps2-an385 with the xrce-transport feature, which installs an XRCE-over-UART vtable when deploy.transport == Some("xrce"). Future boards that need to pre-register a custom transport vtable should override this method in the same pattern.

Failures are the board’s to handle (it owns exit_failure).

Dyn Compatibility

This trait is not dyn compatible.

In older versions of Rust, dyn compatibility was called "object safety", so this trait is not object safe.

Implementors