[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1275233656.15884.4.camel@gandalf.stny.rr.com>
Date: Sun, 30 May 2010 11:34:16 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Avi Kivity <avi@...hat.com>
Cc: Stefan Hajnoczi <stefanha@...il.com>,
linux-perf-users@...r.kernel.org, linux-kernel@...r.kernel.org,
kvm@...r.kernel.org, Frederic Weisbecker <fweisbec@...il.com>,
Marcelo Tosatti <mtosatti@...hat.com>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Stefan Hajnoczi <stefanha@...ux.vnet.ibm.com>,
Johannes Berg <johannes.berg@...el.com>,
Darren Hart <darren@...art.com>
Subject: Re: Perf trace event parse errors for KVM events
On Sun, 2010-05-30 at 17:07 +0300, Avi Kivity wrote:
> On 05/30/2010 05:03 PM, Steven Rostedt wrote:
> >
> >> Right. The tools can fall back to %x/%s based on the structure
> >> descriptor if they can't parse the format string.
> >>
> >>
> > trace-cmd has plugin support to override how to read the format and
> > print it out. It now has the ability to write those plugins in python.
> >
>
> Cool. May make sense to use simpler formatting in the kernel, and use
> trace-cmd plugins for the complicated cases.
>
> It does raise issues with ABIs. Can trace-cmd read plugins from
> /lib/modules/*? We can then distribute the plugins with the kernel.
>
We probably could do that. Perhaps if we can port the python code to
perf, then it would work for both. Then the plugins could be just python
scripts, (or binary .so modules) and have a tools/plugins dir?
The python part probably would be easier to port, since the .so modules
are a bit more specific to trace-cmd.
-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists