Experimental systemtap integrations of LTTng and 'blktrace transport'

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

Hi,

Following this mail are two sets of experimental patches, one
implementing a first attempt at integrating systemtap with LTTng and
the other a first attempt at integrating systemtap with the 'blktrace
transport'.  The 'blktrace transport' I'm referring to is basically
just the non-block-tracing specific kernel and user parts separated
out into separate files/config options that anyone can use, not just
blktrace.

The reason I've provided integrations of both LTTng and the 'blktrace
transport' is because systemtap currently has two different needs - a
default 'immediate' mode, where probe data is made immediately
available to userspace, and a 'bulk' mode which collects as much data
as possible in the kernel and then sends it as efficiently as possible
to userspace in large blocks.  LTTng does the latter very well, as
does blktrace (blktrace uses read() while LTTng uses mmap()), but
blktrace also has a 'live' mode which can be used to provide the
'immediate' mode needed by systemtap.  In addition, LTTng also
provides a comprehensive event management/definition system as well as
a completely re-entrant logging mechanism, while blktrace adds the
ability to do network tracing.

The other reason I went through the exercise of doing this is that
we've also been asked by the kernel developers to push whatever useful
pieces of systemtap infrastructure into the kernel that we can.
Systemtap already has a robust transport, which is a combination of a
read() based 'immediate' mode based on proc files, and straight relay
w/mmap() for 'bulk' mode, and that may indeed be what we want to push
into mainline; these experimental patches basically just attempt to
replicate the same functionality using existing pieces of tracing
infrastructure already in the kernel or presumably soon-to-be in the
kernel.

Just one note - when separating out the blktrace transport, I had to
come up with a name for the common code and named it utt, for 'unified
trace transport', in the hope that it might provide a starting point
for integrating all the useful parts relevant to a generic tracing
transport together.  You shouldn't read too much into that name - it
may well be that a utt.c ends up coming mainly from LTTng or systemtap
and the blktrace stuff merges into that, or it may be that it doesn't
make sense to merge anything together, or that there are other better
tracing transports that I'm not aware of.  Whatever the case, I hope
that this code will provide a sandbox for experimenting with these
options.

Also, standard disclaimer, all this is first cut code, and there are
rough edges that could end up crashing your system, so buyer beware.

Tom