[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] DPRINTF vs tracing
From: |
Blue Swirl |
Subject: |
Re: [Qemu-devel] DPRINTF vs tracing |
Date: |
Sat, 11 Dec 2010 13:28:14 +0000 |
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.