tapset feedback

[Martin Hunt <hunt at redhat dot com>]

I have a bunch of issues with the current tapsets and the way tapsets
are implemented.  Others have written more tapsets than me and I'd
really like to know what your experiences are and what you think of the
following.

1. My biggest issue with the way tapsets are implemented is that there
are no namespaces or ways to limit the scope of a function. Plus the
concepts of code libraries and tapsets are overlapped.

Why is this a problem? Consider the functions contained in
aux_syscalls.stp. Some of these might be tempting for systemtap script
writers to use. However, some of these functions use embedded-C and are
safe to call only from certain contexts. Allowing any script writer to
use them bypasses our safety checks.

Secondly, we have a problem when two tapset writers mistakenly use the
same name for a function. This is a namespace issue that could be solved
by use of some simple naming convention. So it is not serious like the
first problem. But still an annoyance that needs addressing now, before
we have many people writing tapsets. And the solution for the first
problem might be able to solve both.

One thing I would recommend is a conceptual split between "tapsets",
which export probe points and a system library, which would export
general-purpose safe functions.

2. I am not running 2.6.14, 2.6.9-20.ELsmp, or 2.6.9-24.ELsmp on any of
my machines, so I cannot use the syscalls tapset. I mention this not to
pick on that tapset, but to point out that we have a serious maintenance
problem created by the way we have implemented tapsets. 

3. We need to rethink how we set probes on sets of functions.  By this I
mean when we do things like:

probe kernel.syscall.* or
probe kernel.function("sys_*)

We need to consider the following cases:
A. What if one of the functions matched does not exist in the current
kernel?  Right now the compilation fails.
B. What if one of the functions cannot be probed because it is
blacklisted?
C. What if the function is inlined? See
http://sourceware.org/bugzilla/show_bug.cgi?id=1570

So what does this have to do with tapsets? Plenty. Tapsets are basically
a bunch of probe points with code to safely extract data.  Often we are
interested in all the probe points in a tapset, such as with
"kernel.syscall.*". But doing that means that we must have an exact list
of the current syscalls in our running kernel, which brings us back to
problem #2 above.

I can think of several possible solutions. Here's one:

Implement a new probe point "kernel.func" which would be like
"kernel.function" except it would just ignore any function that did not
exist in the currently running system. Also it would match inlines.  Add
to the context tapset a function inlined() which would return 1 if the
current probe point was inlined.

So then we could safely do 
probe kernel.func ("sys_*") 

and for tapsets
probe kernel.syscall.get_mempolicy = kernel.func("sys_get_mempolicy")
{...}
probe kernel.syscall.* {...}

This greatly simplifies the maintenance of tapsets because functions get
added and removed from the kernel all the time both because the kernel
changed and because it can be compiled with different options enabled.

Martin