Problem: SvxLink configuration errors today surface as runtime crashes, silent degradation (when modules fails to load the logic keeps running
partially), or exit(1) with limited diagnostic context. For operators running repeaters unattended, typos and out-of-range values are
a common support burden. There is also no offline way to validate a config before deploying it.
Proposed solutions (seeking your steer before writing code):
- A --check CLI flag on svxlink that parses the config file, runs a set of sanity checks, prints diagnostics with file:line location, and exits without
touching hardware. Intended for CI gating and systemd ExecStartPre=.
- Validation of the GLOBAL section and the standard logic types (SimplexLogic, RepeaterLogic, ReflectorLogic, ReflectorV2Logic, LinkManager). Required keys, numeric ranges, cross-field rules already hand-coded across the codebase would be centralised. Backward compatible, warnings only; errors only when GLOBAL/STRICT_VALIDATION=1.
Two open questions I'd like your input on before I send code:
A) Where should the validator live? Two alternatives:
- C++ in the svxlink binary (new file under src/svxlink/svxlink/). Validator declares schemas for GLOBAL and the logic types with modules unchanged.
- TCL-driven (each module's .tcl registers a schema via new TCL commands, reusing the CFG_* passthrough you already do in Module::initialize at
Module.cpp:87-95). Lighter touch on C++ but moves validation into the event-handler init path.
B) Module participation. Initially I'd leave modules alone and only validate core sections. If it proves useful, modules could opt in later.
Happy to ship this in small stacked PRs:
- just the --check flag doing a bare parse
- line-number tracking in AsyncConfig
- core section
Problem: SvxLink configuration errors today surface as runtime crashes, silent degradation (when modules fails to load the logic keeps running
partially), or exit(1) with limited diagnostic context. For operators running repeaters unattended, typos and out-of-range values are
a common support burden. There is also no offline way to validate a config before deploying it.
Proposed solutions (seeking your steer before writing code):
touching hardware. Intended for CI gating and systemd ExecStartPre=.
Two open questions I'd like your input on before I send code:
A) Where should the validator live? Two alternatives:
Module.cpp:87-95). Lighter touch on C++ but moves validation into the event-handler init path.
B) Module participation. Initially I'd leave modules alone and only validate core sections. If it proves useful, modules could opt in later.
Happy to ship this in small stacked PRs: