What is a tapset?

[Vara Prasad]

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.)
>  
>
Any ideas/insights into what the other mechanisms might be 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. [...]
>>    
>>
>
>  
>
I would like to mention this notion of tapset code is not only for "C" 
based tapsets but also valid for script based tapsets.

>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.  
>  
>
Can you explain what is the complication and what powers that we need to 
define tapsets this method doesn't give?

>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)
>  
>
I am assuming $target_var in the above refers to an argument or local 
variable of "sys_read " probed function, right.
I am also assuming if there happens to be more than one target_var 
defined in the probed function translator is smart enough to find the 
active one and pass it to c_function.
In this above scheme translator needs to find out  where c_function is 
and also find out from debug info what the target_var type is and where 
it is stored so it can pass that when it makes the call to c_function. 
So how is this less complicated then the above proposal and how is this 
more powerful. I agree that you eliminated separate tapset registration 
function to define the probe point. This still doesn't address one of 
the questions you have raised earlier which is "what is the guarantee 
that $target_var is still valid with the changing versions of the kernel?"

Questions:
If c_function wants to export more than one variable, how does it do, 
who allocates memory for those return values
Let us c_function is expecting target_var to be of type int but due to 
kernel changes target_var now become char how does translator know that 
raises error instead of passing wrong type, in my proposal type 
information was part of the registration hence we could verify.
We need to finish details like these.

>   }
>
>Then a systemtap end-user can refer to
>
>   probe syscall("read").plus {
>       print (automatic_var + 1037) 
>  
>
I am guessing you meant this to be "automagic_var" not "automatic_var", 
right.

>   }
>
>  
>
In the above the only difference between probe point definition and 
usage or reference is one has alias and other doesn't. I am not very 
happy with using aliases to differentiate between the two, i would 
rather have a separate syntax for definition like "probedefine", 
"probeexport" etc.

>- FChE
>
>  
>
Based on your above response you seem to agree to the basic concept that 
tapset (both "C" and script) is a probe point and tapset function pair, 
please let me know if this is not true.

As far as i see tapset functions needs three things
a probe point definition
tapset code that exports some variables
optionally environment of the probed function by virtue of arguments and 
local variables

Probe point definition: We have systemtap language constructs e.g 
kernel.function("sys_read") to define the probe points and script based 
tapsets would use that to define the probe points.  In your proposal 
above you are saying we could use the same method to define "C" tapsets, 
i am fine with that.  With this basically tapset authors have to always 
write tapset functions in systemtap language, which is probably not too 
bad, but i don't know how community would react to it.

tapset code: If the data that needs to be exported is simple like 
arguments etc. that doesn't require complicated locking AND it can all 
be expressed in systemtap language we propose to write them in systemtap 
language hence pure script based tapset function.  If there is a need 
for something other than the above then we will call a c function that 
takes care of the complications and gives us some exported variables 
like in the above example you have listed, hence this is a "hybrid" 
script and c based tapset function.

arguments and local variables i.e. environment:  Systemtap will always 
figure out these based on the debug info and pass it to the required 
function.  The way tapset function specifies the required variables is 
by using $var in the call list of the function.

A tapset is a collection of such probe point definitions and tapset code 
in a logical area. From the above a tapset can have only script based 
functions or hybrid or both. In other words there are no restrictions on 
what gets mixed when doing the logical grouping.


Does this summarize what you are thinking?