This is the mail archive of the systemtap@sources.redhat.com 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]

Re: What is a tapset?


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?





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