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]

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()))
}


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