lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1275393544.15884.19.camel@gandalf.stny.rr.com>
Date:	Tue, 01 Jun 2010 07:59:04 -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 Tue, 2010-06-01 at 11:39 +0300, Avi Kivity wrote:
> On 05/30/2010 06:34 PM, Steven Rostedt wrote:
> >
> >> 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.
> >    
> 
> One concern is performance.  Traces tend to be long, and running python 
> code on each line will be slow.
> 
> If trace-cmd integrates a pager and a search mechanism that looks at the 
> binary data instead of the text, we could format only the lines that are 
> displayed.  But that is going to be a lot of work and I don't think it's 
> worth the effort.
> 

Every event gets its own ID. The plugin registers a callback to that ID.
When the ID is hit, the plugin is executed on that event to display its
binary format.

This is done after the data has been saved in binary format to a file.
It may slow down the executing of reading a data file, but it does not
affect the running of the trace one bit.

-- 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

Powered by Openwall GNU/*/Linux Powered by OpenVZ