Re: [Qemu-devel] DPRINTF vs tracing

[Blue Swirl]

On Sat, Dec 11, 2010 at 1:03 PM, Stefan Hajnoczi <address@hidden> wrote:
> Historically, QEMU code has defined per-file DPRINTF() macros for
> debug logging.  A lot of recent patches continue to use this
> technique.
>
> I want to draw attention to tracing support and its advantages over
> DPRINTF().  Tracing is an alternative that solves limitations of the
> DPRINTF() approach:
>
> 1. DPRINTF() requires editing a specific source file and recompiling.
>
> While fine for the original author during development, DPRINTF() are
> not available to users hitting issues in production.  I have not seen
> any bug report threads where users are urged to recompile with a
> DPRINTF() enabled.  That's because it just isn't practical and we're
> losing out on a great source of debug information.
>
> With tracing it is now possible for distros to ship with SystemTap
> support (although LTTng Userspace Tracer and a portable built-in
> tracer are also supported).  I hope we'll soon be able to take
> advantage of this to get detailed information from users experiencing
> bugs.  Let's start adding useful trace events now so we can ask users
> to report detailed information in the future.
>
> 2. DPRINTF() is file-wide and not selectively filtered.
>
> DPRINTF() can only be enabled/disabled for an entire source file at
> compile time.  This leads to noisy outputs that need to be
> post-filtered for the specific DPRINTF() you were looking for.
>
> Trace events can be enabled on a per-event basis.  They can be toggled
> at run-time without recompiling.  Less noise and less recompiling
> makes debugging easier.
>
> 3. DPRINTF() duplicates code.
>
> People have recently pointed out that the number of copy-pasted
> DPRINTF() definitions are ridiculous.
>
> Tracing allows you to focus on defining and calling specific events
> without the boilerplate.  Add one line to the trace-events file and
> call it from your source file, that's it.  You don't need to know
> LTTng UST or SystemTap/DTrace.
>
> For more information on tracing:
> http://git.qemu.org/qemu.git/plain/docs/tracing.txt
>
> See all existing trace events today:
> http://git.qemu.org/qemu.git/plain/trace-events

Fully agree and I'd also add:

4. DPRINTF() is slow.

Tracing moves formatting of data outside of QEMU execution phase to
post processing phase. The overhead of buffering and batch writing of
unformatted binary data is much lower.