On Thu, 13 Sep 2007 16:43:09 -0700The key to the relationship is relay. Systemtap, kprobes, blktrace ,(and others) need the fast user-kernel data hose that relay provides. Trace is a means to simplify and standardize the use of relay. Systemtap adopted this code some time ago in its own runtime. Moving this code into the kernel will allow other tracers to take advantage of the same trace primitives.
David Wilder <dwilder@xxxxxxxxxx> wrote:
These patches provide a kernel tracing interface called "trace".
The motivation for "trace" is to:
- Provide a simple set of tracing primitives that will utilize the high-
performance and low-overhead of relayfs for passing traces data from
kernel to user space.
- Provide a common user interface for managing kernel traces.
- Allow for binary as well as ascii trace data.
- Incorporate features from the systemtap runtime that are
useful to others.
History- Versions of this code have been submitted for review under
a couple of different names. The original submission was called UTT,
it was later re-submitted as GTSC. Christoph Hellwig commented "The
code looks fine ...but the name is just dumb". Following Christoph's
advice, I changed the name to simply "Trace".
This patch addresses review comments made by Christoph Hellwig and Mathieu
Desnoyers. Changes include the addition of a mutex and synchronization
protecting trace state changes (using RCU) and the reduction of the
number of exports.
Patches are against 2.6.23-rc4-mm1
Required patches:
1/2 Trace code and documentation
2/2 Relay reset consumed (required for trace's "rewind" feature")
Signed-off-by: David Wilder <dwilder@xxxxxxxxxx>
Well the code looks neat and easy enough to merge.
What exactly is the relationship between this and systemtap and kprobes and
all the other tracing things which people are doing?