Re: Implementing a generic binary trace interface.

[fche at redhat dot com (Frank Ch. Eigler)]

"Jose R. Santos" <jrs@us.ibm.com> writes:

> 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 [...]

Could you specify *why*?  This is important, because a naive "struct"
construct in systemtap (involving string copying, integer casting) is
likely to rob you of any extra performance you might imagine this
would give you.


> [...]
> probe kernel.function("sys_open")
> {
>       trace_extra.hookid = HOOKID_OPEN;
>       trace_extra.flags = $flags;
> [...]
>       lket_tracer(trace_extra);
> }
> 
> function lket_trace(trace_extra:struct) {
> [...]
>           trace_format.cpu = ...
> [...]
>           trace(trace_format, trace_extra)
> }

How do you folks imagine this working?  Treat the field names as if
they were array indexes, and trace() just iterates over the array?  In
any particular order?

Maybe what you're looking for is programming convenience, such as
varargs, or generic functions, or local arrays?


> [...]
> 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.

You might find that those fixed typing/size constraints are exactly
what allows the Hitachi code to go fast.


- FChE