This is the mail archive of the systemtap@sourceware.org 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: Writing tapset functions for multiple versions


On 07/19/2016 04:06 PM, Felix Lu wrote:
> This is a demonstration of writing functions for multiple
> versions of a tapset.
> 
> Consider the scenario where multiple tapsets are installed, each targeting
> a different version of some process/library. You might want to provide a
> function f that is implemented differently for each version. It is possible
> to create the functions f1 and f2, but this means that the users
> can't create portable scripts that work with all versions. This can now
> be done with function overloading in systemtap 3.0.
> 
> # version1.stp
> function f() {
>   if (pp() !~ "version1")
>     next
>   println("version1")
> }
> probe pp = process("version1/process").function("main") {}
> 
> # version2.stp
> function f() {
>   if (pp() !~ "version2")
>     next
>   println("version2")
> }
> probe pp = process("version2/process").function("main") {}
> 
> $ stap -I . -e 'probe pp {f()}' -c ./version1/process 
> version1
> 
> $ stap -I . -e 'probe pp {f()}' -c ./version2/process
> version2
> 
> Based on the context of the probe, the correct function
> is selected at run time.
> 
> The condition to select an overloaded function can be
> arbitrary. In this case, we check the probe point that is triggered.

(One confusing thing about your example above is that you are using the
'pp' function, but you also have a probe called 'pp'. I think your
example would be clearer if you renamed your probe.)

I'm worried about overhead here. If you have to do that string
comparison in every function, it seems like that would only work for a
small tapset. If you've got a large tapset (or a tapset function that
calls another tapset function in a loop), that overhead is going to add
up. One way to lower to overhead would be to have a set of public
functions that do the pp() check, which are basically wrappers around
private functions that don't.

Are there other ways to lower the overhead? Could each probe set a
global indexed by tid() to some value? (Or by that point would the
string comparison you are using be about the same?)

-- 
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)


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