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.


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.

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.

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?

- FChE


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