[libvirt] [PATCH 00/13] Add multiple trace backend function and add new ftrace backend for libvirt

[yangzy.fnst at cn.fujitsu.com]

> -----Original Message-----
> From: libvir-list-bounces at redhat.com
> [mailto:libvir-list-bounces at redhat.com] On Behalf Of Daniel P. Berrange
> Sent: Saturday, March 22, 2014 12:37 AM
> To: Yang, Zhiyong/杨 志勇
> Cc: libvir-list at redhat.com; Xinghai Yu
> Subject: Re: [libvirt] [PATCH 00/13] Add multiple trace backend function
> and add new ftrace backend for libvirt
>...
> If you just want the ability to record a printable formatted string for
> probes, then I'd much rather just see us improve our logging code, so
> we can request that the libvirt logging system were able to ouput only
> log statements associated with probe points. That's be far simpler to
> do and avoid all the problems with this patchset.
> 
> Regards,
> Daniel

I sincerely appreciate the analysis and feedback from you to my 
patch. As you have pointed out, there are a few of drawbacks in the 
realization of ftrace, such as overhead and the loss of check of 
systemtap/dtrace, which I think are due to technical reasons and
which I must contemplate on. It is determined that I take on my
precious advices and work out a next version of ftrace.

And on that new start point, it might be advisable to re-assess 
the integration of multi-tracer framework(ftrace including) into libvirt, 
which I strongly believe will practically benefit libvirt. 

A big advantage of using ftrace for libvirt is that we can easily merge 
all trace data of libvirt, QEMU, and kernel into one memory buffer.
That makes it really easier for us to investigate a problem. When we 
worked on a problem, we didn't know in which QEMU or libvirt the
root cause resided. we needed to look at logging files of both QEMU
and libvirt in parallel, but it was really hard. The time QEMU and libvirt
has was different so we can't compare the each line of the log easily.

As to the dtrace, which is included in libvirt, is more difficult for 
average users to configurate the D-script. 
For developer, maybe trace is a powerful, flexible and dynamical tool,
but in average users' actual occasion, something such as ftrace
may be more practical.

The communication with the original author of ftrace has commenced 
and it is hopeful that the license will soon be legally permitted to me.

I am looking forward to any exchange of view of whether 
multi-tracer framework(ftrace including) is necessary.

Regards
Yang Zhiyong