Re: What is a tapset?

[Jim Keniston <jkenisto at us dot ibm dot com>]

On Fri, 2005-07-08 at 07:58, Frank Ch. Eigler wrote:
> 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).)

Correct.  The "tapset code" in the pipe_read example would be
{
        fname = "pipe_read"
        reading_from_pipe = 1
}

Vara's terms "tapset code" and "tapset function" have always seemed too
vague to me.  I prefer something like "handler prologue" and "handler
prologue function," respectively.

> 
> The translator is supposed to match a menu of C callback functions

AKA handler prologue functions (HPFs)

> 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).

The HPF procures whatever needed values can't be obtained directly by
translator-emitted code.  For example, for a probed function such as
sys_read(), the HPF might pass back the filename associated with the fd
arg (i.e., $fd).  But the HPF relies on the translator to generate the
appropriate code to procure and pass in the value of $fd.

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

I agree.  I think that the C-tapset idea becomes awkward when you
consider how to map probepoints to HPFs.  The HPFs want to live in
kernel space, but the corresponding HPF registration calls want to live
in user space.

>   
> 
> Instead of this angle, I would propose focusing on a way of calling C
> functions explicitly from the script language.

I agree.

> (FWIW, this sort of
> thing still pains me, and opens up the can of safety worms that Brad
> has referred to on several occasions.)

But the exposure is less than if you code the entire tapset in C.

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

Looks good to me (and sort of familiar :-)).

Two things bother me a little:
- What if your $c_function wants to provide multiple values?  Seems like
multiple function calls are the only option.  Or are we going to allow
the & operator in this context?  Perhaps do the latter only if the
former turns out to be a pain.

- I've never been comfortable with the requirement that you can specify
a handler prologue only if you also specify an alias.  Seems like we
could get past this by using a different keyword (e.g., "export" instead
of "probe") when you're specifying a handler prologue instead of a
handler.

One last thing... Frank and Vara seem to agree that a tapset does NOT
include any predefined handlers (e.g., "canned" tracing code).  Is there
a general consensus on this?

> 
> - FChE
> 

Jim