From: Stefan Hajnoczi <stefanha@gmail.com>
To: Prerna Saxena <prerna@linux.vnet.ibm.com>
Cc: Anthony Liguori <aliguori@us.ibm.com>,
Stefan Hajnoczi <stefanha@linux.vnet.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 13:34:55 +0100 [thread overview]
Message-ID: <AANLkTikXzdGnArympZINF2LPIvRSRSEfjmIrVMYlrvd4@mail.gmail.com> (raw)
In-Reply-To: <4C1B5F74.8040609@linux.vnet.ibm.com>
On Fri, Jun 18, 2010 at 12:58 PM, Prerna Saxena
<prerna@linux.vnet.ibm.com> wrote:
> 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.
Thanks for explaining, I understand what you are doing now. Due to
this special case, the code will dump out the empty trace buffer if
used before anything has been traced (trace_idx=0).
>>> + 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 ?
I still vote for hex instead of decimal :). Since you're already
spinning a new patch it would be nice to put that change in, but no
worries.
> I'll post patches by Monday that addresses your suggestions, and try to get
> it integrated with QMP.
Excellent, thanks. I'd like to put your patches onto my tracing
branch soon and test out the overall workflow of tracing QEMU.
Stefan
next prev parent reply other threads:[~2010-06-18 12:35 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-16 12:35 [Qemu-devel] [PATCH 0/3] Monitor support QEMU trace framework Prerna Saxena
2010-06-16 12:40 ` [Qemu-devel] [PATCH 1/3] Export hash function Prerna Saxena
2010-06-16 12:42 ` [Qemu-devel] [PATCH 2/3] Monitor command 'info trace' Prerna Saxena
2010-06-17 15:08 ` [Qemu-devel] " Stefan Hajnoczi
2010-06-18 11:58 ` Prerna Saxena
2010-06-18 12:34 ` Stefan Hajnoczi [this message]
2010-06-16 12:44 ` [Qemu-devel] [PATCH 3/3] Toggle tracepoint state Prerna Saxena
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-16 13:50 ` [Qemu-devel] Re: [PATCH 0/3] Monitor support QEMU trace framework 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=AANLkTikXzdGnArympZINF2LPIvRSRSEfjmIrVMYlrvd4@mail.gmail.com \
--to=stefanha@gmail.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=prerna@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).