Zephyr OS Logging Modes: Bound Producer Work Before Enabling Immediate Logging

Changing a Zephyr application to immediate logging can make a missing message appear sooner, but it also moves work into the caller's execution path. Before using that change to investigate a timing-sensitive fault, identify which threads and interrupts produce the messages and what the selected backend does before returning. Otherwise, the diagnostic build may change the very behavior being investigated.

This review uses Zephyr 4.4.0. It proposes a way to compare logging configurations; it reports no measured board latency. The question is specifically where logging work executes and how that affects a producer's deadline. Message severity and filtering deserve a separate investigation.

Start with the execution-context change

The tagged logging mode definitions distinguish deferred processing from immediate processing. Deferred mode buffers messages for later handling. Immediate mode processes a log in the calling context, which can include a high-priority interrupt. Its backend must cope with another logging operation preempting the current one.

That distinction makes a source-level replacement such as “enable immediate mode and repeat the test” an experimental change, rather than a neutral observation setting. A call site in a slow housekeeping thread and a call site in an interrupt handler should not receive the same timing approval simply because they use the same logging macro.

Build a short producer inventory. For each relevant call site, record context, normal event rate, burst trigger, maximum message size, and whether a failure path can repeatedly generate it. Include hexdumps and repeated retry errors. A rare fault can create the busiest logging path in the program.

Draw a budget around the caller

Define the interval that matters before instrumenting it. For an interrupt, that could be entry to return; for a control thread, it could be the interval between accepting input and making its output available. The project must choose the actual deadline. This article does not assign a universal acceptable number of microseconds.

Then compare three deliberately identified builds: the normal logging configuration, a configuration with the selected diagnostic messages disabled, and the proposed immediate-logging configuration. Keep compiler settings, application revision, board revision, and workload constant where practical. Preserve the generated configuration with every measurement so a result cannot be attributed to a setting that was never effective.

Use an observation method that does not itself depend on the logging backend under test. A suitable board trace, cycle counter, or external timing observation may help, but each has its own limitations. Record those limitations, including whether interrupts, clock changes, or instrumentation overhead affect the interval.

Follow the backend, not just the macro

A backend is part of the timing experiment. Identify its transport, buffering, locking, and behavior when the receiver is unavailable. Inspect the backend implementation used in the build rather than assuming that every UART, RTT, network, or custom backend has the same blocking behavior.

Test a healthy receiver and the relevant unavailable-receiver condition. If the transport can be disconnected, slowed, or saturated during ordinary use, include that condition in the proposed test plan. Do not infer failure behavior from an empty terminal window. A transport that silently drops output and one that stalls a producer can look equally quiet to an observer.

The logger implementation also shows why deferred logging needs an explicit processing path: message processing checks for an attached backend, handles queued messages, and frees processed entries. An enabled logging call does not prove that its output has reached the observer.

Keep burst handling separate from average throughput

A low average message rate does not establish a safe peak cost. Consider a hypothetical device that emits a brief diagnostic sequence after a link failure. During healthy operation, immediate logging appears harmless. During recovery, several producers report the same failure and a transport becomes slow. The relevant experiment is that combined condition, not the quiet idle run.

For deferred logging, review queue capacity and the actual overflow policy of the chosen configuration. Observe loss reporting where supported. Increasing a queue can absorb some bursts, but it is not evidence that a permanently overloaded consumer can keep up. For immediate logging, review the maximum observed caller interval under the same event sequence.

Keep the two outcomes distinct in the test record: producer timing and diagnostic completeness. A configuration may preserve the deadline while losing messages, or preserve messages while extending execution. Neither result should be summarized merely as “logging works.”

Treat panic behavior as another path

The same tagged implementation has a panic path that notifies active backends and flushes deferred work. Do not assume that observations made in normal steady-state logging describe this path. Equally, do not deliberately trigger destructive product behavior just to collect a trace without an appropriate test setup.

If fault-time evidence matters, define what information must survive and which output mechanism is available at that moment. Record the limits honestly. A normal-mode benchmark is not proof that a partially failed system can deliver its last message.

Make a bounded decision

Approve immediate logging for the intended investigation only after the actual producer contexts and backend behavior are understood. Keep the configuration identifiable and explain whether it is diagnostic-only or intended for the released product. If a message disappears when the timing-neutral observation is used, investigate that discrepancy instead of treating the most convenient log as ground truth.

A useful review record contains the effective mode, backend revision, observed interval, workload, receiver condition, loss evidence, and unresolved limits. The result is a defensible measurement plan for the device in front of you, without claiming that one Zephyr logging mode is universally safe or universally wrong.