From: Prerna Saxena <prerna@linux.vnet.ibm.com>
To: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
Cc: qemu-devel@nongnu.org, Anthony Liguori <aliguori@us.ibm.com>,
kvm@vger.kernel.org, Stefan@us.ibm.com,
Luiz Capitulino <lcapitulino@redhat.com>,
Maneesh Soni <maneesh@linux.vnet.ibm.com>,
Ananth <ananth@linux.vnet.ibm.com>
Subject: Re: [PATCH 2/3] Monitor command 'info trace'
Date: Fri, 18 Jun 2010 17:28:44 +0530 [thread overview]
Message-ID: <4C1B5F74.8040609@linux.vnet.ibm.com> (raw)
In-Reply-To: <20100617150810.GA15845@stefan-thinkpad.transitives.com>
Hi Stefan, Jan,
Thanks for taking a look.
On 06/17/2010 08:38 PM, Stefan Hajnoczi wrote:
> On Wed, Jun 16, 2010 at 06:12:06PM +0530, Prerna Saxena wrote:
>> diff --git a/simpletrace.c b/simpletrace.c
>> index 2fec4d3..239ae3f 100644
>> --- a/simpletrace.c
>> +++ b/simpletrace.c
>> @@ -62,3 +62,16 @@ void trace4(TraceEvent event, unsigned long x1, unsigned long x2, unsigned long
>> void trace5(TraceEvent event, unsigned long x1, unsigned long x2, unsigned long x3, unsigned long x4, unsigned long x5) {
>> trace(event, x1, x2, x3, x4, x5);
>> }
>> +
>> +void do_info_trace(Monitor *mon)
>> +{
>> + unsigned int i, max_idx;
>> +
>> + max_idx = trace_idx ? trace_idx : TRACE_BUF_LEN;
>
> trace_idx is always in the range [0, TRACE_BUF_LEN). There is no need
> to perform this test.
I only display the logged contents in the trace buffer (till trace_idx)
, and not the entire trace buffer. Only when the index is full that the
entire buffer is displayed.
>
>> +
>> + for (i=0; i<max_idx ;i++) {
>
> Whitespace "i=0; i<max_idx ;i++". "i = 0; i< max_idx; i++" is pretty
> common across QEMU.
>
I'll fix this.
>> + monitor_printf(mon, "Event %ld : %ld %ld %ld %ld %ld\n",
>> + trace_buf[i].event, trace_buf[i].x1, trace_buf[i].x2,
>> + trace_buf[i].x3, trace_buf[i].x4, trace_buf[i].x5);
>
> Getting only numeric output is the limitation of a binary trace. It
> would probably be possible to pretty-print without much additional code
> by using the format strings from the trace-events file.
>
> I think the numeric dump is good for now though. Hex is more compact
> than decimal and would make pointers easier to spot. Want to change
> this?
>
I agree, but we can let this be a todo till after the first prototype
goes upstream ?
>> + }
>> +}
>> diff --git a/tracetool b/tracetool
>> index 9ea9c08..2c73bab 100755
>> --- a/tracetool
>> +++ b/tracetool
>> @@ -130,6 +130,7 @@ void trace2(TraceEvent event, unsigned long x1, unsigned long x2);
>> void trace3(TraceEvent event, unsigned long x1, unsigned long x2, unsigned long x3);
>> void trace4(TraceEvent event, unsigned long x1, unsigned long x2, unsigned long x3, unsigned long x4);
>> void trace5(TraceEvent event, unsigned long x1, unsigned long x2, unsigned long x3, unsigned long x4, unsigned long x5);
>> +void do_info_trace(Monitor *mon);
>> EOF
>>
>> simple_event_num=0
>> @@ -289,6 +290,7 @@ tracetoh()
>> #define TRACE_H
>>
>> #include "qemu-common.h"
>> +#include "monitor.h"
>
> qemu-common.h forward-declares Monitor, I don't think you need
> monitor.h.
>
Right.
> Stefan
I'll post patches by Monday that addresses your suggestions, and try to
get it integrated with QMP.
--
Prerna Saxena
Linux Technology Centre,
IBM Systems and Technology Lab,
Bangalore, India
WARNING: multiple messages have this Message-ID (diff)
From: Prerna Saxena <prerna@linux.vnet.ibm.com>
To: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
Cc: Anthony Liguori <aliguori@us.ibm.com>,
kvm@vger.kernel.org, qemu-devel@nongnu.org,
Luiz Capitulino <lcapitulino@redhat.com>,
Maneesh Soni <maneesh@linux.vnet.ibm.com>,
Ananth <ananth@linux.vnet.ibm.com>,
Stefan@us.ibm.com
Subject: [Qemu-devel] Re: [PATCH 2/3] Monitor command 'info trace'
Date: Fri, 18 Jun 2010 17:28:44 +0530 [thread overview]
Message-ID: <4C1B5F74.8040609@linux.vnet.ibm.com> (raw)
In-Reply-To: <20100617150810.GA15845@stefan-thinkpad.transitives.com>
Hi Stefan, Jan,
Thanks for taking a look.
On 06/17/2010 08:38 PM, Stefan Hajnoczi wrote:
> On Wed, Jun 16, 2010 at 06:12:06PM +0530, Prerna Saxena wrote:
>> diff --git a/simpletrace.c b/simpletrace.c
>> index 2fec4d3..239ae3f 100644
>> --- a/simpletrace.c
>> +++ b/simpletrace.c
>> @@ -62,3 +62,16 @@ void trace4(TraceEvent event, unsigned long x1, unsigned long x2, unsigned long
>> void trace5(TraceEvent event, unsigned long x1, unsigned long x2, unsigned long x3, unsigned long x4, unsigned long x5) {
>> trace(event, x1, x2, x3, x4, x5);
>> }
>> +
>> +void do_info_trace(Monitor *mon)
>> +{
>> + unsigned int i, max_idx;
>> +
>> + max_idx = trace_idx ? trace_idx : TRACE_BUF_LEN;
>
> trace_idx is always in the range [0, TRACE_BUF_LEN). There is no need
> to perform this test.
I only display the logged contents in the trace buffer (till trace_idx)
, and not the entire trace buffer. Only when the index is full that the
entire buffer is displayed.
>
>> +
>> + for (i=0; i<max_idx ;i++) {
>
> Whitespace "i=0; i<max_idx ;i++". "i = 0; i< max_idx; i++" is pretty
> common across QEMU.
>
I'll fix this.
>> + monitor_printf(mon, "Event %ld : %ld %ld %ld %ld %ld\n",
>> + trace_buf[i].event, trace_buf[i].x1, trace_buf[i].x2,
>> + trace_buf[i].x3, trace_buf[i].x4, trace_buf[i].x5);
>
> Getting only numeric output is the limitation of a binary trace. It
> would probably be possible to pretty-print without much additional code
> by using the format strings from the trace-events file.
>
> I think the numeric dump is good for now though. Hex is more compact
> than decimal and would make pointers easier to spot. Want to change
> this?
>
I agree, but we can let this be a todo till after the first prototype
goes upstream ?
>> + }
>> +}
>> diff --git a/tracetool b/tracetool
>> index 9ea9c08..2c73bab 100755
>> --- a/tracetool
>> +++ b/tracetool
>> @@ -130,6 +130,7 @@ void trace2(TraceEvent event, unsigned long x1, unsigned long x2);
>> void trace3(TraceEvent event, unsigned long x1, unsigned long x2, unsigned long x3);
>> void trace4(TraceEvent event, unsigned long x1, unsigned long x2, unsigned long x3, unsigned long x4);
>> void trace5(TraceEvent event, unsigned long x1, unsigned long x2, unsigned long x3, unsigned long x4, unsigned long x5);
>> +void do_info_trace(Monitor *mon);
>> EOF
>>
>> simple_event_num=0
>> @@ -289,6 +290,7 @@ tracetoh()
>> #define TRACE_H
>>
>> #include "qemu-common.h"
>> +#include "monitor.h"
>
> qemu-common.h forward-declares Monitor, I don't think you need
> monitor.h.
>
Right.
> Stefan
I'll post patches by Monday that addresses your suggestions, and try to
get it integrated with QMP.
--
Prerna Saxena
Linux Technology Centre,
IBM Systems and Technology Lab,
Bangalore, India
next prev parent reply other threads:[~2010-06-18 11:58 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-16 12:35 [PATCH 0/3] Monitor support QEMU trace framework Prerna Saxena
2010-06-16 12:35 ` [Qemu-devel] " Prerna Saxena
2010-06-16 12:40 ` [PATCH 1/3] Export hash function Prerna Saxena
2010-06-16 12:40 ` [Qemu-devel] " Prerna Saxena
2010-06-16 12:42 ` [PATCH 2/3] Monitor command 'info trace' Prerna Saxena
2010-06-16 12:42 ` [Qemu-devel] " Prerna Saxena
2010-06-17 15:08 ` Stefan Hajnoczi
2010-06-17 15:08 ` [Qemu-devel] " Stefan Hajnoczi
2010-06-18 11:58 ` Prerna Saxena [this message]
2010-06-18 11:58 ` Prerna Saxena
2010-06-18 12:34 ` Stefan Hajnoczi
2010-06-18 12:34 ` [Qemu-devel] " Stefan Hajnoczi
2010-06-16 12:44 ` [PATCH 3/3] Toggle tracepoint state Prerna Saxena
2010-06-16 12:44 ` [Qemu-devel] " Prerna Saxena
2010-06-17 16:03 ` Stefan Hajnoczi
2010-06-17 16:03 ` [Qemu-devel] " Stefan Hajnoczi
2010-06-18 12:24 ` Prerna Saxena
2010-06-18 12:46 ` Stefan Hajnoczi
2010-06-18 12:46 ` Stefan Hajnoczi
2010-06-16 13:50 ` [PATCH 0/3] Monitor support QEMU trace framework Jan Kiszka
2010-06-16 13:50 ` [Qemu-devel] " Jan Kiszka
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4C1B5F74.8040609@linux.vnet.ibm.com \
--to=prerna@linux.vnet.ibm.com \
--cc=Stefan@us.ibm.com \
--cc=aliguori@us.ibm.com \
--cc=ananth@linux.vnet.ibm.com \
--cc=kvm@vger.kernel.org \
--cc=lcapitulino@redhat.com \
--cc=maneesh@linux.vnet.ibm.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@linux.vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.