On Fri, May 21, 2010 at 12:13 PM, Jan Kiszka <jan.kiszka@xxxxxxxxxxx> wrote:
> Stefan Hajnoczi wrote:
>> Trace events should be defined in trace.h. Events are written to
>> /tmp/trace.log and can be formatted using trace.py. Remember to add
>> events to trace.py for pretty-printing.
>
> When already writing to a file, why not reusing QEMU's logging
> infrastructure ("log <foo>" / "-d foo")? Shouldn't make a huge
> performance difference if the data is saved in clear-text.
> Also, having support for ftrace's user space markers would be a very
> nice option (only an option as it's Linux-specific), see
> http://lwn.net/Articles/366796.
Thanks for the links.
I think using the platform's tracing facility has many advantages.
The main one being that we can focus on QEMU/KVM development rather
than re-implementing tracing infrastructure :).
It may be possible to have SystemTap, DTrace, or nop static trace
event code. A platform with no tracing support can only use the nop
backend, which results in a build without static trace events.
Platforms with tracing support can build with the appropriate backend
or nop. The backend tracing facility is abstracted and most of QEMU
doesn't need to know which one is being used.
I hadn't seen trace markers. However, I suspect they aren't ideal for
static trace events because logging an event requires a write system
call. They look useful for annotating kernel tracing information, but
less for high frequency/low overhead userspace tracing.
Stefan
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
