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] |
parasadav wrote:Any ideas/insights into what the other mechanisms might be for synchronous probes.
[...]
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.)
I would like to mention this notion of tapset code is not only for "C" based tapsets but also valid for script based tapsets.
[...]
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. [...]
Can you explain what is the complication and what powers that we need to define tapsets this method doesn't give?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.
I am assuming $target_var in the above refers to an argument or local variable of "sys_read " probed function, right.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 guessing you meant this to be "automagic_var" not "automatic_var", right.
Then a systemtap end-user can refer to
probe syscall("read").plus {
print (automatic_var + 1037)
}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.
- FChEBased 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.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |