On Sun, Feb 27, 2011 at 6:16 PM, Paolo Bonzini <pbonz...@redhat.com> wrote: > On 02/27/2011 06:02 PM, Stefan Hajnoczi wrote: >> >> On Sun, Feb 27, 2011 at 3:13 PM, Paolo Bonzini<pbonz...@redhat.com> >> wrote: >>> >>> On 02/27/2011 03:58 PM, Stefan Hajnoczi wrote: >>>> >>>> + * Trace records are written out by a dedicated thread. The thread >>>> waits >>>> for >>>> + * records to become available, writes them out, and then waits again. >>>> + */ >>>> +static pthread_mutex_t trace_lock = PTHREAD_MUTEX_INITIALIZER; >>>> +static pthread_cond_t trace_available_cond = PTHREAD_COND_INITIALIZER; >>>> +static pthread_cond_t trace_empty_cond = PTHREAD_COND_INITIALIZER; >>>> +static bool trace_available; >>>> +static bool trace_writeout_enabled; >>> >>> Please use QemuThread. >> >> The tracing code itself should use avoid core QEMU code. Otherwise we >> can't trace QemuThread - we'd have an infinite loop. > > Hmm, right... they'll use stdio to trace Win32 then... :) I was actually > thinking more of the code duplication. > > But do you really need tracing at such a low level? I'd expect tracing > wrappers like qemu_lock_mutex_iothread, not mutexes in general.
We can get away with it for some codepaths but it adds new constraints that are hard to check against. For example, simpletrace uses get_clock() but we need to limit ourselves as much as possible. If that function calls any other core QEMU code like qemu_malloc(), then we risk infinite recursion because qemu_malloc() has a useful trace event. Stefan
