> -----Original Message----- > From: libvir-list-bounces@xxxxxxxxxx > [mailto:libvir-list-bounces@xxxxxxxxxx] On Behalf Of > yangzy.fnst@xxxxxxxxxxxxxx > Sent: Tuesday, April 01, 2014 5:28 PM > To: libvir-list@xxxxxxxxxx > Subject: Re: [PATCH 00/13] Add multiple trace backend function > and add new ftrace backend for libvirt > > > > -----Original Message----- > > From: libvir-list-bounces@xxxxxxxxxx > > [mailto:libvir-list-bounces@xxxxxxxxxx] On Behalf Of Daniel P. > Berrange > > Sent: Saturday, March 22, 2014 12:37 AM > > To: Yang, Zhiyong/杨 志勇 > > Cc: libvir-list@xxxxxxxxxx; Xinghai Yu > > Subject: Re: [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@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/libvir-list -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list