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: Slides demonstrating our systemtap usage in production


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


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