This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
tapset beginnings
- From: "Frank Ch. Eigler" <fche at redhat dot com>
- To: systemtap at sources dot redhat dot com
- Date: Thu, 11 Aug 2005 12:39:25 -0400
- Subject: tapset beginnings
Hi -
Here's a little blurb about how to actually start writing functional
"tapset" code, given the present and impending facilities in the
translator. The idea is to inspire our Intel & IBM partners to start
writing interface and sample "tapset" code, and start deprecating some
of the C kprobes experiments so far performed. (This presumes that we
can overcome the annoying elfutils-dependency-related build problems.)
Let's take the first bit of timestamp_tapset.txt for example. The
portion of interest here is how to expose various kinds of time to
scripts.
HPET, when available at all, is a small pool of independent counters,
shared with user-space applications. HPET timers #0 and maybe #1 are
reserved for kernel use during startup (see ARCH/kernel/time*.c).
User code can request control/mmap of the others. Accessing the
kernel's timer may be the simplest thing, however there is no
kernel-module-accessible API for this that I can find. Using
intra-kernel but unexported functions (hpet_readl, ...), we could get
to the data, but this might be controversial. I also haven't found an
easy way to get the memory-mapped address for the counters. So, let's
leave HPET aside for now.
Similar considerations apply to RTC, ACPI timer, and other hardware
counters. If there is no intra-kernel API to get at them, it would be
tricky or controversial for systemtap to do so.
OTOH, do_gettimeofday is a no-brainer. We should just do it:
-------- tapset/something.stp
%{
#include <linux/time.h>
%}
// here is a millisecond variant
function gettimeofday_ms () %{
struct timeval tm;
do_gettimeofday (& tm);
THIS->__retvalue = (tm.tv_sec * 1000) + (tm.tv_usec / 1000);
%}
-------- sample.stp
probe begin,end {
log ("timeofday=" . hexstring (gettimeofday_ms ()))
}
Similarly the jiffies, monotonic_clock(), ... values can all be
exposed. All related function definitions can go into a single file,
which I'm starting to commit to src/tapset/timestamp_functions.stp.
In fact, I plan to build the contextinfo tapset variables in the
syntactic form of function calls, many of them implemented just like
this.
A single session-wide atomic_t counter could be implemented thusly.
It of course generalized to multiple atomic counters, per-cpu stuff,
as desired.
-------- guru-mode script or tapset/foo* once generalized
%{
#include <asm/atomic.h>
atomic_t my_little_pony = ATOMIC_INIT (0);
%}
function pony_increment () %{
THIS->__retvalue = atomic_inc_return (& my_little_pony);
%}
-------- sample.stp
probe begin,end {
log ("counter=" . string (pony_increment()))
}