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