Re: Implementing a generic binary trace interface.

[Tom Zanussi <zanussi at us dot ibm dot com>]

Frank Ch. Eigler writes:
 > 
 > zanussi wrote:
 > 
 > > [...]
 > 
 > Thank you for your rather detailed proposal.
 > 
 > 
 > > [...]
 > > probe kernel.function("sys_open")
 > > {
 > > 	data.hook_id = HOOKID_OPEN
 > > 	fill_in_common(data)
 > > 	data.flags = $flags;
 > > [...]
 > > }
 > > 
 > > function fill_in_common(data)
 > > {
 > > 	data.timestamp = timestamp_us();
 > > }
 > 
 > >From this discussion, it seems to me that the sole use of this sort of
 > struct construct is for purposes of tracing.  There are no language
 > elements proposed for generically extracting information such as field
 > names / values.  Have you thought about what happens in connection
 > with conditionals / loops?  How should functions be type checked when
 > they take structs?  And return them?  And how are these connected to
 > arrays, when they are also passed by reference?  Can they be global?
 > Why not?
 > 
 > This seems to me as a too special-purpose and of too limited
 > application for it to show up in the script language in this
 > misleadingly general-looking form.
 > 

Yes, you're right - the sole purpose is for tracing.  I'll admit I
wasn't entirely comfortable attempting to usurp such an important
language construct for such trivial reasons, but hey, nobody else was
using it ;-)

 > Here is a possible way of accomplishing the same goal - lightweight
 > binary tracing.  No new misleading notation, just special
 > functions, like printf* today.
 > 
 > # probe kernel.function("sys_open")
 > # {
 > # 	trace("hook_id", HOOKID_OPEN)
 > # 	trace_common()
 > # 	trace("flags", $flags)
 > # 	[...]
 > # }
 > # 
 > # function trace_common()
 > # {
 > # 	trace("timestamp", timestamp_us())
 > # }
 > 
 > The translator could generate similar code to your sketch: a field
 > assignment in a synthesized buffer struct for each executed trace().
 > It could avoid widening $target values to systemtap types, or include
 > explicit encoding/casting directives.  It could infer a "flush" at the
 > end of a probe that calls trace().  It could invent field names if you
 > don't care to give one for each call site.
 > 

Sounds like it should do the trick.  Thanks for the suggestion.

 > For that matter, this could all be hidden in printf itself, with
 > special formatting directives.  (Don't assume that this would
 > necessarily invoke the kernel vsnprintf.  The translator could be a
 > smarter than to call the runtime _stp_printf function.)
 > 
 > By the way, in either the structy or printy design, how do you expect
 > the actual binary struct metadata to be used at the end?  How would
 > the binary trace data be decoded?
 > 

There are probably as many different ways of doing this as there are
different trace applications.

For instance, I have working code that registers event types by
creating proc files which describe them.  Each contains enough
information to completely decode any event in the event stream
e.g. event id, event size and for each field, type, length (for
supporting arrays/strings), etc.

Using this scheme, and since I'm hard-pressed to find a reason to
define more than 256 events, my trace 'format' consists of a single
byte at the beginning of each event.

Tom