On 16 October 2015 at 13:33, Markus Armbruster <arm...@redhat.com> wrote: > We have a couple of related features, and I'd like to get some clarity > on how exactly they should be used. > > 1. Tracing > > Documented in docs/tracing.txt. > > Each trace event can be individually controlled with -trace and with > monitor command trace-event. Wildcards work. Monitor command "info > trace-event" shows their status. > > Supports a wealth of tracing backends: nop (compiles out tracing > completely), stderr (prints trace to stderr), "simple", "ftrace", > "dtrace", ... Range from "trivially easy" to "complex power tool".
The major problem with this is it is a compile time choice (especially the choice of backend), and our default backend is 'nop'. > 2. Ad hoc printing > > We have 108 files with some #define DPRINTF(), and probably some more > sailing under different flags. The ones that aren't useless should > probably be tracepoints. > > 3. "qemu/log.h" logging > > Sports a "mask", where each bit enables a certain set of log > messages. Control the mask with "-d item,..." Try "-d help" to see > acceptable items. > > Logs to stderr by default, can be redirected with "-D <logfile>". This, though it is a bit ad-hoc, always exists, always behaves the same way, and doesn't require anybody to rebuild QEMU to enable tracing. I think having a more consistent approach to logging would be great, though. thanks -- PMM
