Expand description
Launch remap rules as ONE const table in flash – issue 1971, RFC-0107 step 1.
The launch file’s <remap from= to=/> rules describe the IMAGE, not one
executor. Before this every executor carved a RAM table of 16 rules
(RemapRule, 404 B each on thumbv7em: 6,464 B per backing) and the
generated C/C++ entry filled it with one nros_cpp_declare_remap call per
rule, on every tier’s executor. Now codegen emits the rules once, as a
static const array of string pointers, and hands it to the runtime once
(set_launch_remaps, nros_cpp_set_launch_remaps) before any tier is
set up. Every executor reads that table; none copies it.
Layering is unchanged: these rules are the AUTHORITATIVE tier of
crate::names::resolve_name_layered, and --ros-args -r rules (still in
the executor’s RAM table, see ExecutorSizing::remaps) are the fallback.
The Rust entry already worked this way: its launch remaps are a &'static
slice on RuntimeCtx, and this table is the C/C++ twin of it.
Structs§
- BadLaunch
Remap - Why
set_launch_remapsrefused a table. - Launch
Remap - One launch remap rule, in the shape the generated C/C++ entry emits:
four NUL-terminated strings in
.rodata.
Functions§
- launch_
remaps - The installed launch remap table (empty until
set_launch_remaps). - set_
launch_ remaps - Install the image’s launch remap table. Every executor reads it from then
on, on every road (C and C++ registration,
Executor::create_node’s handle).