linux-perf-users.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Ahern <daahern@cisco.com>
To: Frederic Weisbecker <fweisbec@gmail.com>
Cc: linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org,
	acme@ghostprotocols.net, mingo@elte.hu, peterz@infradead.org,
	paulus@samba.org, tglx@linutronix.de
Subject: Re: [PATCH 4/6] perf script: dump software events too
Date: Tue, 01 Mar 2011 07:18:55 -0700	[thread overview]
Message-ID: <4D6D004F.5010602@cisco.com> (raw)
In-Reply-To: <AANLkTikwsuBGVfB6uu7=H0jbL+2YbbvX=ea6rLwNP8w-@mail.gmail.com>



On 03/01/2011 07:09 AM, Frederic Weisbecker wrote:
> 
> That's not on the right place. This is going to print the events even
> when we launch scripts. We only want to print them when we launch
> perf script without a script, which falls back to printing events
> (look at default_scripting_ops).
> 
> Like I suggested you, it's better to extend struct
> scripting_ops::process_event()
> to take the whole event and let the handler decide what to do.
> Python and Perl scripting engines can just extract the raw sample and
> do like they did before.
> But print_event(), which is the process_event() handler for the
> default_scripting_ops,
> can handle the new printing features.
> 
> That's also more flexible, this lets Python and Perl scripting engines
> be extendable
> to handle the rest of the event later.

I don't follow what you mean.

This is the same place that tracepoints are dumped. In the
PERF_TYPE_TRACEPOINT case process_event == print_event which dumps the
lines to stdout.

I came in added a switch that invokes a different handler for software
events. Software events will be processed differently than tracepoint.
The print_event function and its pretty_print function are not designed
to dump software events (and eventually hardware events).

David

  reply	other threads:[~2011-03-01 14:18 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-28  3:52 [PATCH 0/6 v3] perf events: Add realtime clock event, time-of-day strings to script output David Ahern
2011-02-28  3:52 ` [PATCH 1/6] perf events: Introduce realtime clock event David Ahern
2011-02-28  3:52 ` [PATCH 2/6] perf events: plumbing for PERF_SAMPLE_READ and read_format David Ahern
2011-02-28  3:52 ` [PATCH 3/6] perf record: add time-of-day option David Ahern
2011-03-01 14:29   ` Peter Zijlstra
2011-03-01 14:35     ` David Ahern
2011-03-01 15:35       ` Peter Zijlstra
2011-03-01 15:41         ` David Ahern
2011-03-01 16:00           ` Peter Zijlstra
2011-03-01 16:09             ` David Ahern
2011-03-01 16:37               ` Peter Zijlstra
2011-03-01 16:45                 ` David Ahern
2011-03-01 17:07                   ` Arnaldo Carvalho de Melo
2011-03-01 17:09                     ` Arnaldo Carvalho de Melo
2011-03-01 22:28                   ` Peter Zijlstra
2011-03-01 22:35                     ` David Ahern
2011-03-02 14:16   ` Thomas Gleixner
2011-03-02 14:28     ` David Ahern
2011-03-02 17:28       ` Thomas Gleixner
2011-03-03 14:29         ` David Ahern
2011-03-03  8:51       ` Ingo Molnar
2011-03-03 14:33         ` David Ahern
2011-02-28  3:52 ` [PATCH 4/6] perf script: dump software events too David Ahern
2011-03-01 14:09   ` Frederic Weisbecker
2011-03-01 14:18     ` David Ahern [this message]
2011-03-01 15:11       ` Frederic Weisbecker
2011-03-01 16:11         ` David Ahern
2011-03-01 16:24           ` Frederic Weisbecker
2011-03-01 16:49           ` Arnaldo Carvalho de Melo
2011-02-28  3:52 ` [PATCH 5/6] perf script: Prepend lines with time-of-day string David Ahern
2011-02-28  3:52 ` [PATCH 6/6] perf stat: treat realtime-clock as nsec counter David Ahern
2011-02-28  3:55 ` [PATCH 0/6 v3] perf events: Add realtime clock event, time-of-day strings to script output David Ahern

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=4D6D004F.5010602@cisco.com \
    --to=daahern@cisco.com \
    --cc=acme@ghostprotocols.net \
    --cc=fweisbec@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=paulus@samba.org \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    /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).