Expand description
The executor backing’s placement arithmetic — issue 1197.
§Why this is its own crate
phase-392 W6 moved the executor’s per-entry storage into a .bss static. On
an RTOS the allocator reservation it used to come out of is itself fixed, so
whatever sizes that reservation has to know how big the backing is.
The size is arena + tables. The arena is plain arithmetic
nros-node/build.rs already computes. The tables are repr(Rust) layout —
field order, padding and niche packing are the compiler’s to choose and to
CHANGE between versions — so they can never be re-derived outside it. That is
the sizes-header mirror class (0088 -> 0114 -> 0122 -> 0123 -> 0245 -> 0268)
this tree has re-fixed six times.
So the arithmetic takes the per-type facts as DATA. nros-node supplies what
its compiler says while building for the target; a build script supplies
units recovered for a target it is not itself compiling (the way nros-c
recovers EXECUTOR_OPAQUE_U64S through nros-sizes-build). One
implementation, two sources of the inputs.
It is a separate crate rather than a pub fn in nros-node for one reason:
a build script runs on the HOST, and a build-dependency on nros-node would
give it a host-compiled nros-node — the wrong layout, silently. This crate
is no_std and dependency-free so both sides can reach it.
§What it does NOT decide
The counts. cbs/sc/nodes/arena come from nros-node/build.rs and,
on a synced leaf, from the derived env nros sync writes (issues 0827,
1061). This crate only places regions.
Structs§
- Counts
- How many of each region the image needs.
- Offsets
- Byte offset of each region, plus the total size and alignment.
- Region
Unit - Size and alignment of one region’s element type.
- Region
Units - Every element type the backing carves a table of, in declaration order.
Functions§
- offsets
- Place every region and report the offsets, total size and alignment.
- size_
of_ backing - The backing’s total size in bytes — what a reservation has to hold.