Module backdrop 

Persistent scenario state that lives across every Step in a #[ktstr_test] run.

Tests usually express “a scheduler is under load for N seconds” as a Step sequence. Some tests also want entities that persist for the WHOLE run — a long-running binary payload, a synthetic workload that spans the whole scenario, a cgroup whose identity is referenced by multiple Steps. Those go in a Backdrop.

Step vs Backdrop

• A Step is bounded: everything it creates (cgroups, workload handles, payload handles) is torn down when the step finishes. The runtime enforces this automatically — no explicit teardown op is required.
• A Backdrop is persistent: what it sets up lives for the entire Step sequence. Its cgroups are created once before the first Step and RAII-removed at scenario end; its payloads spawn once and are killed (with metric emission) after the last Step tears down.

In the “bursty load + scheduler stress test” pattern:

• The bursty payload (a persistent fio, a running stress-ng) is a Backdrop::push_payload(...) entry — it runs THROUGHOUT the test, irrespective of which Step is currently applying ops.
• Each Step handles a discrete phase (“settle”, “inject contention”, “measure”) with its own CgroupDefs that come and go.

Steps may reference Backdrop-owned cgroups by name through cgroup-addressing ops (Op::SetCpuset, Op::MoveAllTasks, etc.) — name lookups resolve step-local first, then fall through to the Backdrop. Step-local cgroups must not shadow a Backdrop cgroup name. Step-local Op::RemoveCgroup / Op::StopCgroup targeting a Backdrop cgroup is permitted; later Steps that reference the removed cgroup by name surface a kernel-layer cgroup missing error rather than getting a Backdrop typo caught early.

Structs

Backdrop

Persistent state for a Step sequence.