[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
> yangzy.fnst at cn.fujitsu.com
> Sent: Tuesday, April 01, 2014 5:28 PM
> To: libvir-list at redhat.com
> Subject: Re: [libvirt] [PATCH 00/13] Add multiple trace backend function
> and add new ftrace backend for libvirt
> 
> 
> > -----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

Ping!
Regards
Yang Zhiyong

> 
> --
> libvir-list mailing list
> libvir-list at redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list