Logging CFT Weekly [2025-07-22]

[arsibo]

Participants

Saumya Rai
Ankur Satle
Hahn Thomas
Hoppe Nils
Buehrer Ulrich
Gangadhara Maddikery Raghavendra
Babanin Andrey
Sievert Arvid

Agenda & Meeting Minutes

1. Status

• Readme, Detailed Design doc availible in baselib/docs
  • https://github.com/eclipse-score/baselibs/blob/main/score/mw/log/README.md
  • https://github.com/eclipse-score/baselibs/blob/main/score/mw/log/design/remote_logging.plantuml
• Convertion to puml required => Todo: Generate Issues to do
• process gap analysis S-Core Process gap analysis for MW:log #494 (comment)*
  • generate issues and discuss who contributes what

3. Detailed Design => feedback for next meeting required

4. decision about Rust API
   

5. @ALL Review the logging req. https://eclipse-score.github.io/score/pr-1388/features/analysis-infra/logging/docs/requirements/mw-fr_logging_req.html

6. AoB

   • https://sdvworkinggroup.slack.com/archives/C089XP2PGQZ

[Saumya-R]

Rust-C++ Logging Integration: Strategy Comparison

Common to Both

• C++ logging backend with:

  • App ID tagging
  • Context support
  • Fatal-level handling (e.g., terminate after logging)
  • Verbose + non-verbose logging path
  • ISO 26262 / ASIL-B compatible behavior (e.g., deterministic, testable)

• Rust wrapper, with:

  • Same public API surface (info!(), warn!(), fatal!(), etc.)
  • FFI communication to C++
  • Performance optimization (esp. for trace/debug)
  • One of:
    • Fork and extend the log crate
    • Fully custom implementation
    • Integrate with defmt

---

Strategy Options

2a. Fork and Extend log Crate

a. Implementation

• Fork log, maintain its API (info!(), warn!(), debug!()), but modify internals.
• Inject app_id, fatal!(), context fields into Record.
• Rewrite Logger trait to bridge to your C++ backend.
• Optionally add compile-time filtering, richer metadata, etc.

b. Pros

Benefit	Detail
Rust ecosystem compatibility	All existing crates using log macros (hyper, tokio, etc.) will continue working seamlessly.
Less boilerplate	Reuses log!() macro definitions, levels, and filtering logic.
Incremental adoption	You can initially just plug in your logger and evolve features without breaking users.
Thread-safe and well-tested	log already handles global logger setup, filtering, static registration.

c. Cons

Issue	Detail
Maintenance burden of a fork	log is widely used and regularly updated. You must track upstream changes.
Inflexibility of log::Record	You may have to hack around its immutable Record structure to inject context like app_id.
Minimal by design	Hard to layer complex contextual info like async span traces or task-local app_id.
Forked macros are brittle	Hygiene issues or procedural macro limitations may arise while modifying log!() variants.
ASIL B certification harder	log crate wasn't built for certifiability; upstream code audit may not satisfy safety requirements.

---

2b. Fully Custom Logging Framework

a. Implementation

• Build macro API (info!(), fatal!(), etc.) from scratch.
• Define your own Record, Level, Logger, and filtering logic.
• Use thread_local! or scoped context for app_id, task_id, etc.
• Call C++ logger through FFI inside your own sink (log_to_cpp()).
• Add advanced features:
  • Static and dynamic context
  • Task-local values
  • Compile-time level filters
  • Fatal-only fast paths

b. Pros

Benefit	Detail
Full control	Tailor every part: macros, structure, filtering, performance tuning.
ASIL B suitability	Fewer dependencies, deterministic paths, certifiable logic.
Custom features	Structured logging, task IDs, timestamps, context injection, etc.
No upstream churn	Stability and long-term maintainability under your control.

c. Cons

Issue	Detail
No log ecosystem support	Third-party crates using log macros won’t integrate automatically.
Higher engineering cost	All components (macros, internals, FFI) must be built from scratch.
Testing burden	Thread safety, panic behavior, filtering logic need comprehensive testing.
Learning curve	Custom APIs introduce maintenance risk for new developers.

---

3. Use defmt

a. Implementation

• Use defmt::* macros (defmt::info!(), etc.), optimized for embedded logging.
• Extend or bridge defmt internals to route to C++ backend (via #[export_name] or custom transport layer).
• Capture defmt logs from Rust and map them to your structured C++ format.
• Use defmt::global_logger!() to plug in your implementation.
• defmt is an excellent option if your target platform is no-std or extremely memory-constrained, and you can control the entire toolchain.

b. Pros

Benefit	Detail
Zero-cost formatting	Log messages are encoded into a compact binary stream at compile time.
Compile-time filtering	Unused log levels (e.g. debug!) are eliminated entirely in release mode.
Highly efficient	No heap allocation, ideal for safety-critical and embedded systems.
Minimal runtime overhead	Great for performance-sensitive environments or bare-metal systems.
Defmt global_logger! is extendable	You can define a logger that sends logs via C++ FFI.

c. Cons

Issue	Detail
Custom toolchain integration	defmt is tightly coupled with probe-rs and defmt-print. Needs adaptation for C++ logging.
Incompatible with log macros	Any crate using log won’t log anything unless explicitly rewritten to use defmt.
Limited log metadata	Defmt’s static format strings don’t easily support dynamic key-value logging or complex context.
Embedded-first	Originally designed for no-std embedded targets — overkill for host-side use unless deeply integrated.
Nonstandard formatting	Log strings are encoded and decoded at build/run-time via defmt-print. Not human-readable at runtime without tooling.

---

Technical Detail Comparison

Area	Fork log	Self-Implemented	defmt
Global init	set_logger()	Custom or global logger with scope/task support	defmt::global_logger!()
Log Record	log::Record (static)	Full custom struct	Static tokenized format
Performance tuning	Limited	Full control (#[inline], filtering, early exit)	Best-in-class for embedded
Macros	Wrap log!()	Fully custom	Built-in defmt::* macros
Thread/task context	Difficult to inject	Custom context stack via TLS	Not supported natively
FFI integration	Indirect (adapter)	Direct sink to log_to_cpp()	Needs custom Logger impl
Auditability for ASIL-B	Compromised by external code	Fully verifiable	Strong (if no defmt-print reliance)
Crate compatibility	Full	None	None
Memory and runtime footprint	Moderate	Tunable	Ultra low
Compile-time filtering	Only with log feature flags	Via #[cfg()] or custom	Built-in at compile time
Dynamic formatting	String formatting	Full structurable support	Not supported (static formatting only)
Best for	General-purpose, ecosystem-compat	ASIL-B, embedded+host	Pure embedded, ultra low footprint

---

Recommended Strategy

Use Case	Suggested Variant
General-purpose logging + ecosystem interop	Variant 1 (Fork log)
Safety-critical, ASIL B focused, C++ integrated systems	Variant 2 (Self-contained)
Embedded-first or bare-metal targets	Variant 3 (defmt)
Long-term platform with custom runtime/task system	Variant 2, optionally with log::Log trait for compatibility
Need log compat + extended features	Hybrid: implement log::Log trait, but route to your logger internals

---