This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Implementing a generic binary trace interface.


Jose R. Santos wrote:
Hi folks,

My team is currently implementing a trace tool using SystemTap that currently does logging by means of printf mechanism. We want to move to a binary trace format but there is no such mechanism on SystemTap for doing this. I've looked at what the folks at Hitachi have done with BTI, but this seems to force a specific trace format that is not suitable for what we need. Ideally, the trace format should be left to the tapset using the interface not the BTI. I propose to slightly alter the BTI from Hitachi to allow other trace implementations to use the trace format that's most convenient for the people implementing them.

To facilitate this, Tom Zanussi has been talking about implementing a basic form struct to the SystemTap language. The basic idea of how the tapset would use the new BTI and struct data types looks like:

probe kernel.function("sys_open")
{
     trace_extra.hookid = HOOKID_OPEN;
     trace_extra.flags = $flags;
     trace_extra.mode = $mode;
     trace_extra.name = $filename;
     trace_extra.fd = $fd;

     lket_tracer(trace_extra);
}


function lket_trace(trace_extra:struct) {


         trace_format.timestamp = ...
         trace_format.cpu = ...
         trace_format.....
         .....

         trace(trace_format, trace_extra)
}


Unlike the BTI current implementation, the format of the trace hook is defined by lket_trace and not by the generic interface. This design has the following benefits over the Hitachi interface.


1) It allows for anyone to implement their own trace hooks as they see fit. Making it a truly generic interface.

2) It does not limit the number or type of arguments that a trace hook can have. The current implementation limits you to 16 data points of size long.


Aside from the support to add struct to the SystemTap language, the rest of the changes to the BTI should be pretty straight forward and they would not significantly impact the current work that Hitachi has done with their implementation.


Thoughts?

-JRS

Are you proposing something like the trace buffers in perfmon2?


http://www.hpl.hp.com/techreports/2004/HPL-2004-200R1.html
http://sourceforge.net/projects/perfmon2

The perfmon2 allows multiple types of trace buffers, each has a unique idetifier. The perfmon2 trace buffers can be interpretted in what ever manner desired. OProfile has used a version of this mechanism in perfmon to collect data on ia64 machines. The code that writes to the buffer can be custom. There is a default trace buffer that writes a data to the buffer.

-Will

-Will


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]