public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
From: David Smith <dsmith@redhat.com>
To: Felix Lu <flu@redhat.com>, systemtap@sourceware.org
Subject: Re: Writing tapset functions for multiple versions
Date: Wed, 20 Jul 2016 14:05:00 -0000	[thread overview]
Message-ID: <70bd0aff-e6bb-3131-e270-598363dfb188@redhat.com> (raw)
In-Reply-To: <540973478.22718523.1468962366224.JavaMail.zimbra@redhat.com>

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)

  reply	other threads:[~2016-07-20 14:05 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <64396010.22700492.1468961291108.JavaMail.zimbra@redhat.com>
2016-07-19 21:06 ` Felix Lu
2016-07-20 14:05   ` David Smith [this message]
2016-07-20 14:47     ` Felix Lu
2016-07-20 15:04       ` David Smith
2016-07-20 15:25         ` Felix Lu
2016-07-20 16:23           ` Felix Lu
2016-07-20 16:38             ` Josh Stone

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=70bd0aff-e6bb-3131-e270-598363dfb188@redhat.com \
    --to=dsmith@redhat.com \
    --cc=flu@redhat.com \
    --cc=systemtap@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).