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 Stefan
