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 kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
