Re: Implementing a generic binary trace interface.

[Mathieu Desnoyers <compudj at krystal dot dyndns dot org>]

Have you looked at the LTTng/LTTV trace format ?

It supports nested structures, unions, sequences, arrays. It uses completely
portable types and optionnaly does dynamic data alignment.

It's described there :

http://ltt.polymtl.ca/svn/ltt/branches/poly/doc/developer/format.html


If what you are looking for is something "truly generic", you might be
interested.


Mathieu


* Jose R. Santos (jrs@us.ibm.com) 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
> 
OpenPGP public key:              http://krystal.dyndns.org:8080/key/compudj.gpg
Key fingerprint:     8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68