rust-lang
Proposal: Extend log crate with contextual, typed, and fatal-level logging
Motivation: Automotive Use Case
- Contextual / Hierarchical Logging
- Current target (module path) is too flat for complex automotive applications where multiple layers/modules may reuse common subsystems.
- Developers need to distinguish who logged what not only by module but also by parent/ancestor context.
- Add optional hierarchical context (e.g. ECU → Subsystem → Component).
- Such context could be attached automatically (per logger instance) and optionally extended by the user.
- Enables better traceability of log origins in safety-critical systems.
- Type-Aware Logging
- Today everything is stringified, discarding type info needed by automotive backends (e.g. DLT expects type fidelity: numeric vs string vs struct).
- Proposal: allow passing typed values directly (info!(42), info!("user_id" = 43), info!(User { id: 7 })).
- Preserves fidelity for DLT and similar tools, enables filtering/sorting, while staying backward-compatible and simple for developers.
- Fatal Log Level
- Current Error conflates recoverable and unrecoverable failures.
- Add a Fatal level for logging critical, fail-stop conditions.
- Essential for automotive where safety hazards must be identified and escalated distinctly.
Benefits
- Improves interoperability with standards (e.g. DLT, AUTOSAR logging).
- Strengthens suitability for safety-critical domains (ISO 26262 compliance).
- Still lightweight: could be added as opt-in features, maintaining compatibility.
- Contextual / Hierarchical Logging
Note that target != module path, though it's the default. You can set the target yourself: info!(target: "my target"). I've personally used this for access log set a specific target which can then be used for filtering later.
- Current target (module path) is too flat for complex automotive applications where multiple layers/modules may reuse common subsystems.
- Developers need to distinguish who logged what not only by module but also by parent/ancestor context.
- Add optional hierarchical context (e.g. ECU → Subsystem → Component).
- Such context could be attached automatically (per logger instance) and optionally extended by the user.
- Enables better traceability of log origins in safety-critical systems.
I think this will add quite a bit of overhead if this entire hierarchy needs to be kept in memory. What I do is add an id to each log so they can be grouped. My use case is handling requests so it's easy, an id per request, I don't know what an equivalent would be in automotive software though. Would something like this be possible for your use case?
- Type-Aware Logging
Have you tried key-value logging: https://docs.rs/log/latest/log/kv/index.html, it's fully typed.
- Fatal Log Level
Duplicate of #334, which discusses adding additional logging level.
Contextual / Hierarchical Logging
This seems to be an insatnce of Logforth's (thread-local) Diagnostic and needs not to be a feature in log.
Fatal Log Level
From your description, this can be resolved either:
- Move recoverable errors to the WARN level.
- Tag fatal logs with a "fatal" target and specially handling it in the log impl.