From: Feng Tang <feng.tang@intel.com>
To: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: <mingo@elte.hu>, <a.p.zijlstra@chello.nl>,
<robert.richter@amd.com>, <ak@linux.intel.com>,
<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/3] perf script: Add general python handler to process non-tracepoint events
Date: Fri, 18 May 2012 10:48:56 +0800 [thread overview]
Message-ID: <20120518104856.0ba4da7a@feng-i7> (raw)
In-Reply-To: <20120517154315.GA2636@infradead.org>
Hi Arnaldo,
Thanks for your review!
On Thu, 17 May 2012 12:43:15 -0300
Arnaldo Carvalho de Melo <acme@redhat.com> wrote:
> Em Wed, May 16, 2012 at 08:59:13PM +0800, Feng Tang escreveu:
> > This patch just follows Robert Richter's idea and the commit 37a058ea0
> > "perf script: Add generic perl handler to process events"
> > to similarly add a python handler for general events other than tracepoints.
> >
> > For non-tracepoint events, this patch will try to find a function named
> > "process_general_event" in the python script, and pass the event
>
> But in perl isn't it named "process_event"? Can't we use the same
> convention in the python case?
Good point, will comply with the perl code.
>
> > header, attribute, perf_sample, raw_data in format of raw string. And
> > the python script can use "struct" module's unpack function to disasemble
> > the needed info and process.
> >
> > Signed-off-by: Feng Tang <feng.tang@intel.com>
> > ---
> > .../util/scripting-engines/trace-event-python.c | 60
> > +++++++++++++++++++- 1 files changed, 59 insertions(+), 1 deletions(-)
> >
> > diff --git a/tools/perf/util/scripting-engines/trace-event-python.c
> > b/tools/perf/util/scripting-engines/trace-event-python.c index
> > c2623c6..aaf2679 100644 ---
> > a/tools/perf/util/scripting-engines/trace-event-python.c +++
> > b/tools/perf/util/scripting-engines/trace-event-python.c @@ -324,6 +325,63
> > @@ static void python_process_event(union perf_event *pevent __unused,
> > Py_DECREF(t); }
> >
> > +static void python_process_general_event(union perf_event *pevent __unused,
> > + struct perf_sample *sample,
> > + struct perf_evsel *evsel __unused,
> > + struct machine *machine __unused,
> > + struct thread *thread __unused)
> > +{
> > + PyObject *handler, *retval, *t;
> > + static char handler_name[64];
> > + unsigned n = 0;
> > + void *data = sample->raw_data;
> > +
> > + t = PyTuple_New(MAX_FIELDS);
> > + if (!t)
> > + Py_FatalError("couldn't create Python tuple");
> > +
> > + sprintf(handler_name, "process_general_event");
>
> Strange use of sprintf, if you think it is safe to not bounds check, use
> strcpy(), if you still want to use sprintf, please instead use:
>
> snprintf(handler_name, sizeof(handler_name), "%s", "process_event");
Ok, will change it. Following is the update patch:
>From 87b855a7c85438f45e1fc89250e392c1d6365ec6 Mon Sep 17 00:00:00 2001
From: Feng Tang <feng.tang@intel.com>
Date: Fri, 11 May 2012 16:58:05 +0800
Subject: [PATCH] perf script: Add general python handler to process non-tracepoint events
This patch just follows Robert Richter's idea and the commit 37a058ea0
"perf script: Add generic perl handler to process events"
to similarly add a python handler for general events other than tracepoints.
For non-tracepoint events, this patch will try to find a function named
"process_event" in the python script, and pass the event attribute,
perf_sample, raw_data in format of raw string. And the python script can
use "struct" module's unpack function to disasemble the needed info and process.
Signed-off-by: Feng Tang <feng.tang@intel.com>
---
.../util/scripting-engines/trace-event-python.c | 60 +++++++++++++++++++-
1 files changed, 59 insertions(+), 1 deletions(-)
diff --git a/tools/perf/util/scripting-engines/trace-event-python.c b/tools/perf/util/scripting-engines/trace-event-python.c
index c2623c6..6daa12f 100644
--- a/tools/perf/util/scripting-engines/trace-event-python.c
+++ b/tools/perf/util/scripting-engines/trace-event-python.c
@@ -31,6 +31,7 @@
#include "../event.h"
#include "../thread.h"
#include "../trace-event.h"
+#include "../evsel.h"
PyMODINIT_FUNC initperf_trace_context(void);
@@ -205,7 +206,7 @@ static inline struct event *find_cache_event(int type)
return event;
}
-static void python_process_event(union perf_event *pevent __unused,
+static void python_process_tracepoint(union perf_event *pevent __unused,
struct perf_sample *sample,
struct perf_evsel *evsel __unused,
struct machine *machine __unused,
@@ -324,6 +325,63 @@ static void python_process_event(union perf_event *pevent __unused,
Py_DECREF(t);
}
+static void python_process_general_event(union perf_event *pevent __unused,
+ struct perf_sample *sample,
+ struct perf_evsel *evsel,
+ struct machine *machine __unused,
+ struct thread *thread __unused)
+{
+ PyObject *handler, *retval, *t;
+ static char handler_name[64];
+ unsigned n = 0;
+ void *data = sample->raw_data;
+
+ t = PyTuple_New(MAX_FIELDS);
+ if (!t)
+ Py_FatalError("couldn't create Python tuple");
+
+ snprintf(handler_name, sizeof(handler_name), "%s", "process_event");
+
+ handler = PyDict_GetItemString(main_dict, handler_name);
+ if (handler && !PyCallable_Check(handler)) {
+ handler = NULL;
+ goto exit;
+ }
+
+ /* Pass 3 parameters: event_attr, perf_sample, raw data */
+ PyTuple_SetItem(t, n++, PyString_FromStringAndSize(
+ (const char *)&evsel->attr, sizeof(evsel->attr)));
+ PyTuple_SetItem(t, n++, PyString_FromStringAndSize(
+ (const char *)sample, sizeof(*sample)));
+ PyTuple_SetItem(t, n++, PyString_FromStringAndSize(
+ data, sample->raw_size));
+
+ if (_PyTuple_Resize(&t, n) == -1)
+ Py_FatalError("error resizing Python tuple");
+
+ retval = PyObject_CallObject(handler, t);
+ if (retval == NULL)
+ handler_call_die(handler_name);
+exit:
+ Py_DECREF(t);
+}
+
+static void python_process_event(union perf_event *pevent,
+ struct perf_sample *sample,
+ struct perf_evsel *evsel,
+ struct machine *machine,
+ struct thread *thread)
+{
+ switch (evsel->attr.type) {
+ case PERF_TYPE_TRACEPOINT:
+ python_process_tracepoint(pevent, sample, evsel, machine, thread);
+ break;
+ /* Reserve for future process_hw/sw/raw APIs */
+ default:
+ python_process_general_event(pevent, sample, evsel, machine, thread);
+ }
+}
+
static int run_start_sub(void)
{
PyObject *handler, *retval;
--
1.7.1
next prev parent reply other threads:[~2012-05-18 2:52 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-16 12:59 [PATCH 1/3] perf script: Add general python handler to process non-tracepoint events Feng Tang
2012-05-16 12:59 ` [PATCH 2/3] perf script: Replace "struct thread" with "struct addr_location" as a parameter for "process_event()" Feng Tang
2012-05-17 15:45 ` Arnaldo Carvalho de Melo
2012-05-17 16:08 ` David Ahern
2012-05-17 16:22 ` Arnaldo Carvalho de Melo
2012-05-30 16:10 ` David Ahern
2012-05-16 12:59 ` [PATCH 3/3] perf script/python: Pass thread/dso name and symbol info to event handler in python Feng Tang
2012-05-17 15:47 ` Arnaldo Carvalho de Melo
2012-05-18 2:55 ` Feng Tang
2012-05-18 15:38 ` Arnaldo Carvalho de Melo
2012-05-19 14:13 ` Feng Tang
2012-05-17 15:43 ` [PATCH 1/3] perf script: Add general python handler to process non-tracepoint events Arnaldo Carvalho de Melo
2012-05-18 2:48 ` Feng Tang [this message]
2012-05-18 15:34 ` Arnaldo Carvalho de Melo
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=20120518104856.0ba4da7a@feng-i7 \
--to=feng.tang@intel.com \
--cc=a.p.zijlstra@chello.nl \
--cc=acme@redhat.com \
--cc=ak@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=robert.richter@amd.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.