Skip to main content

Module control_catalog

Module control_catalog 

Source
Expand description

SRD-23 — the dynamic-control capability catalog.

Controls are declared imperatively into the live component tree at run time (Component::controls().declare(...)), which makes them enumerable through that tree once it exists — dryrun=controls, SRD-23 §“Enumeration”. But that only surfaces the controls a given run happened to declare: anything conditional (rate, only when a phase sets rate:) or adapter-owned (cql_trace_rate, only when the CQL adapter is active) is invisible until its conditions are met. That asymmetry is why concurrency (always declared) feels discoverable and rate does not.

This module adds the complementary capability tier: a static, pre-instantiation description of every control the binary can declare, readable by nmbrs describe controls without running anything. Each ControlDesc is the single source of truth — the imperative declaration derives its name / value-type / default / range / gauge from the descriptor (via ControlDesc::build_u32 / ControlDesc::build_f64 / ControlDesc::build_rate), so the discovery surface and the live control can never drift.

Owners: core controls (concurrency, rate) live here; adapter controls are contributed by each adapter’s supported_controls and unioned in by all_controls.

Structs§

ControlDesc
Static, declarative description of one dynamic control’s capability. See the module docs: this is the single source the imperative declaration derives from and that describe controls reads, so they cannot drift.
ControlEntry
One row of the capability catalog: a descriptor plus its owner.

Enums§

ControlOwner
Where a control’s descriptor is contributed from — shown by describe controls so a user knows which subsystem owns the knob.
ControlValueType
The value shape of a control, as projected onto the f64-writable surface every writer (TUI e, POST /controls, polydat control_set, optimize.servo) shares.
DeclaredWhen
The condition under which a control is actually declared on the component tree — the why isn’t this knob here? a user needs when a control is absent from a given run.

Constants§

CONCURRENCY
concurrency — the fiber count the executor maintains for a phase. Always declared, so it is the one control present in every run.
RATE
rate — the cycle-rate limiter (ops/sec). Declared only when a phase sets rate:; that field value seeds the control (and is the warmup an optimize.servo: rate retargets from).
RETRY_EXEMPLAR_MAX_HZ
retry_exemplar_max_hz — emission-frequency ceiling for retry exemplars; admissions over it are squelched and counted (reported on the next emitted line). 0 = uncapped.
RETRY_EXEMPLAR_RATE
retry_exemplar_rate — retry-error counter-exemplar sampling (SRD-82 Part 3b / exec_events). Push-on-set: the applier is one atomic store into the activity’s shared ExemplarConfig; samplers read it only on their retry path. Ops that pin retry_exemplar_* params hold private cells this control does not move.

Functions§

all_controls
Enumerate every control the binary can declare — core plus each registered adapter’s supported_controls — for nmbrs describe controls. This is the static capability view (SRD-23 §“Enumeration”), distinct from the instance view dryrun=controls walks over the live component tree.
core_controls
The core controls every build supports (subject to each one’s DeclaredWhen condition). Adapter controls are added by all_controls.