Re: What is a tapset?

[fche at redhat dot com (Frank Ch. Eigler)]

parasadav wrote:

> [...]
> In the last weeks call people expressed concern that the concept of
> tapset is not clear and well defined. This is my attempt to define
> it. [...]

> Kprobes is the basic mechanism used by systemtap to get the control of
> execution in the case of synchronous probes. [...]

(BTW, it is the primary mechanism, but is unlikely to remain the sole
mechanism even for synchronous probes.)

> [...]

You recite a pretty well-understood set of definitions for probe
handler functions and probe points.  The novel stuff is your notion of
"tapset code"


> tapset code: For each probepoint, a piece of code that makes available
> named values a.k.a. "exported variables" that an end user can refer to
> in their scripts. [...]

Recalling a telephone conversation with Vara, let me paraphrase this
thusly.  Vara's notion of C-language extensions for probe handlers
consists of the provision of automagic variables to probe handler
scripts.  (I suppose the closest existing concept is that of probe
aliases, which can include variable assignments
(e.g. testsuite/semok/thirteen.stp).)

The translator is supposed to match a menu of C callback functions
against the current probe point specification, and a set of available
variables that those callback functions can procure.  The translator
is also supposed to supply these callback functions with a few more
auxiliary data values (like target-side local variables).

If this is a fair characterization, then I believe that this is a bit
over-complicated and under-powered for what we need.  

Instead of this angle, I would propose focusing on a way of calling C
functions explicitly from the script language.  (FWIW, this sort of
thing still pains me, and opens up the can of safety worms that Brad
has referred to on several occasions.)  With such a mechanism, it
would be simple for a tapset author to define a probe alias, something
like this, and get it installed in the script library search path:

   probe syscall("read").plus = kernel.function("sys_read") { 
       automagic_var = $c_function ($target_var)
   }

Then a systemtap end-user can refer to

   probe syscall("read").plus {
       print (automatic_var + 1037) 
   }


- FChE