All of lore.kernel.org
 help / color / mirror / Atom feed
From: Darren Hart <dvhltc@us.ibm.com>
To: Steven Rostedt <rostedt@goodmis.org>,
	"lkml, " <linux-kernel@vger.kernel.org>
Subject: [PATCH 2/2] RFC: Use opaque record type in pevent accessor functions
Date: Wed, 16 Dec 2009 16:35:47 -0800	[thread overview]
Message-ID: <4B297CE3.6040600@us.ibm.com> (raw)
In-Reply-To: <4B297C79.2090004@us.ibm.com>

>From 1f76a9521a63e456a950f1a57e69d9dfc36ab001 Mon Sep 17 00:00:00 2001
From: Darren Hart <dvhltc@us.ibm.com>
Date: Wed, 16 Dec 2009 15:25:30 -0800
Subject: [PATCH 2/2] RFC: Start of a tracecmd swig wrapper for python

Introduce a python tracecmd module for use in rapidly prototyping
tracing applications. The interface description is provided in
tracecmd.i, it identifies which functions are available from within
python. A test python script is provided as tracecmd-test.py.

These bindings are expected to change significantly. Eventually I
would like to wrap this automated binding with more pythonic objects,
most likely including Trace and Event objects which merge the
functionality of tracecmd-input, pevent, record, and event structures.
This will make development of python apps much more accessible to many
application developers.

For now, this is mostly a proof of concept and is no where near
complete. It can however open a trace file and read all the events from
it, displaying them by CPU in chronological order.

Signed-off-by: Darren Hart <dvhltc@us.ibm.com>
---
 swig.sh          |   18 ++++++++++++++++++
 tracecmd-test.py |   35 +++++++++++++++++++++++++++++++++++
 tracecmd.i       |   39 +++++++++++++++++++++++++++++++++++++++
 3 files changed, 92 insertions(+), 0 deletions(-)
 create mode 100755 swig.sh
 create mode 100755 tracecmd-test.py
 create mode 100644 tracecmd.i

diff --git a/swig.sh b/swig.sh
new file mode 100755
index 0000000..c53e7a2
--- /dev/null
+++ b/swig.sh
@@ -0,0 +1,18 @@
+#!/bin/sh
+
+# Temporary hack of a build script, eventually we'll incoroporate this
+# into the Makefile. You may have to update the includes to point to your
+# python installation.
+
+rm tracecmd_wrap.c tracecmd_wrap.o _tracecmd.so &> /dev/null
+
+swig -python tracecmd.i
+
+gcc -fpic -c  -I/usr/include/python2.6/ -I/usr/lib/python2.6/config \
+    trace-ftrace.c trace-seq.c trace-util.c \
+    trace-input.c parse-events.c tracecmd_wrap.c
+
+gcc -shared trace-ftrace.o trace-seq.o trace-util.o \
+    trace-input.o parse-events.o \
+    tracecmd_wrap.o -o _tracecmd.so
+
diff --git a/tracecmd-test.py b/tracecmd-test.py
new file mode 100755
index 0000000..1ad2ea4
--- /dev/null
+++ b/tracecmd-test.py
@@ -0,0 +1,35 @@
+#!/usr/bin/env python
+
+from tracecmd import *
+
+# Let's move the following into a new Trace object constructor
+filename = "trace.dat"
+trace_file = open(filename)
+handle = tracecmd_open(trace_file.fileno())
+tracecmd_read_headers(handle)
+tracecmd_init_data(handle)
+
+# These should be members, i.e. Trace.cpus
+pe = tracecmd_get_pevent(handle)
+cpus = tracecmd_cpus(handle)
+print "Trace %s contains data for %d cpus" % (filename, cpus) 
+
+# FIXME: this doesn't print anything...
+tracecmd_print_events(handle)
+
+print "Cycling through the events for each CPU"
+for cpu in range(0,cpus):
+    print "CPU", cpu
+    rec = tracecmd_read_data(handle, cpu)
+    while True:
+        rec = tracecmd_read_data(handle, cpu)
+        if rec:
+            # these should be members of a Record object
+            pid = pevent_data_pid(pe, rec)
+            comm = pevent_data_comm_from_pid(pe, pid)
+            type = pevent_data_type(pe, rec)
+            event = pevent_data_event_from_type(pe, type)
+            print "\t%f %s: pid=%d comm=%s type=%d" % \
+                  (record_ts(rec), event_name(event), pid, comm, type)
+        else:
+            break
diff --git a/tracecmd.i b/tracecmd.i
new file mode 100644
index 0000000..f43a90b
--- /dev/null
+++ b/tracecmd.i
@@ -0,0 +1,39 @@
+// tracecmd.i
+%module tracecmd
+%{
+/* The following functions provide accessors to the C struct members
+ * we want to eliminate these if at all possible with changes to the
+ * tracecmd API.
+ */
+#include "parse-events.h"
+char *event_name(struct event *e) {
+        return e->name;
+}
+
+/* Python can't handle long long, convert to double in seconds */
+double record_ts(struct record *rec) {
+        return (double)(rec->ts) / 1000000000;
+}
+%}
+
+/* tracecmd functions */
+struct tracecmd_input *tracecmd_open(int fd);
+int tracecmd_read_headers(struct tracecmd_input *handle);
+int tracecmd_init_data(struct tracecmd_input *handle);
+int tracecmd_cpus(struct tracecmd_input *handle);
+struct pevent *tracecmd_get_pevent(struct tracecmd_input *handle);
+/* FIXME: this didn't print anything */
+void tracecmd_print_events(struct tracecmd_input *handle);
+/* FIXME: need a way to free the record */
+struct record *tracecmd_read_data(struct tracecmd_input *handle, int cpu);
+
+/* pevent, record, event functions */
+int pevent_data_pid(struct pevent *pevent, struct record *rec);
+int pevent_data_type(struct pevent *pevent, struct record *rec);
+struct event *pevent_data_event_from_type(struct pevent *pevent, int type);
+const char *pevent_data_comm_from_pid(struct pevent *pevent, int pid);
+
+
+/* custom wrappers to account for opaque pointers */
+char *event_name(struct event *e);
+double record_ts(struct record *rec);
-- 
1.6.3.3

-- 
Darren Hart
IBM Linux Technology Center
Real-Time Linux Team

  reply	other threads:[~2009-12-17  0:35 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-17  0:34 [PATCH 1/2] Use opaque record type in pevent accessor functions Darren Hart
2009-12-17  0:35 ` Darren Hart [this message]
2009-12-17 10:17   ` [PATCH 2/2 V2] tracecmd: Start of a tracecmd swig wrapper for python Darren Hart
2009-12-17 15:51     ` Steven Rostedt
2009-12-17 15:51 ` [PATCH 1/2] Use opaque record type in pevent accessor functions Steven Rostedt

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=4B297CE3.6040600@us.ibm.com \
    --to=dvhltc@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rostedt@goodmis.org \
    /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.