All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.