This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: Slides demonstrating our systemtap usage in production
- From: "Yichun Zhang (agentzh)" <agentzh at gmail dot com>
- To: "Frank Ch. Eigler" <fche at redhat dot com>
- Cc: systemtap at sourceware dot org
- Date: Tue, 10 Sep 2013 11:58:19 -0700
- Subject: Re: Slides demonstrating our systemtap usage in production
- Authentication-results: sourceware.org; auth=none
- References: <CAB4Tn6MPxVst0bUO3n0Ns=+_24pw4wdKFGxvQRGPDh8Que9Taw at mail dot gmail dot com> <y0m61u9ha5b dot fsf at fche dot csb>
Hello Frank!
On Mon, Sep 9, 2013 at 4:01 PM, Frank Ch. Eigler wrote:
>
> It turns out that a lot of what you are doing in this package is
> supported or almost supported in the base. Would you be interested in
> porting over the unique bits?
>
Yeah sure. Actually that was the plan :) stap++ is good for playing
with various features and notations :)
>
> $^exec_path: ISTR there was a PR for this, but can't find it now.
> This functionality could go into core stap, implementing
> the exact same heuristic. See how
> stap -e 'probe process.FOO {}' -c 'CMD ARGS...'
> is implemented. One complication with this is compile-server
> mode (where -x-expansion cannot be relied upon to match -x on
> the invoking host). We could just punt on this for now.
>
Great! :)
>
> $^libFOO_path: Could be a combined with the above:
> stap -e 'probe process.library("FOO").BAR { }' -c 'CMD ARGS...'
>
Nice :)
>
> $^arg_NAME: Have you looked at the
> stap ... -G name=value
> mechanism for setting integer/string globals? If you desire
> named parameters in a context other than for global variables,
> perhaps stap could grow a -M macro='value' option, which would
> work like a
> @define macro %( value %)
> in an stpm file.
>
I like the idea of the -M macro=value option because I often use this
for contexts where global variables cannot be used, as in probe
declarators, for instance, the func-latency-distr tool written in
stap++:
https://github.com/agentzh/stapxx/blob/master/samples/func-latency-distr.sxx
For default values, maybe we can make -M override existing macros
defined in the .stp/.stpm files?
>
> macros: since stap 2.0, see smakarov's @define facility:
> @define foo(x) %( 2, 4, @x %)
> probe begin { println ( @foo(6) ) }
>
Oh yeah, this is very useful :)
>
> tapset modules: we hadn't seen a requirement for module/namespacing constructs
> in the tapset, so things work more automagically:
>
I prefer proper module systems because
1. it can reduce the startup time of systemtap when there are a huge
number of tapset functions ready for use.
2. it's easy to specify dependency relationships among different sets
of tapsets.
>
> @pfunc(): likely implementable as a single stap macro:
> @define pfunc(x) %( process.function(@x) %)
>
Yes, you are right :) The @pfunc thing can be implemented just as a
macro in a predefined tapset file :)
Thanks!
-agentzh