This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: Better handling of arguments/literals from the command-line?
- From: "Stone, Joshua I" <joshua dot i dot stone at intel dot com>
- To: "Theodore Ts'o" <tytso at mit dot edu>
- Cc: "systemtap at sources dot redhat dot com" <systemtap at sources dot redhat dot com>
- Date: Mon, 6 Oct 2008 13:01:36 -0700
- Subject: Re: Better handling of arguments/literals from the command-line?
- References: <E1KmL7X-0000cI-6Y@closure.thunk.org>
Theodore Ts'o wrote:
> If the argument were passed into the kernel, then it would be posible to
> cache the compiled "strace.stp" script once, instead of having to
> re-evaluate it for every single process ID. Is there a good reason it
> isn't handle this way currently?
The arguments are handled almost like preprocessor tokens, so you can do
things like "probe kernel.function(@1), timer.sec($2) {}". The timer
could easily resolve its parameter at runtime, but that's harder for the
function probe.
If you only care about a pid, then target() as Mark pointed out is
probably the best choice, but here's a more generalized mechanism.
There's a little-advertised feature that global strings and longs can be
initialized with module parameters to staprun. Thus you can do this:
$ stap -e 'global foo=0; probe begin { println(foo); exit() }' \
-p4 -m printfoo
printfoo.ko
$ staprun printfoo.ko
0
$ staprun printfoo.ko foo=42
42
For parameters that are only used as literals in function/probe bodies,
we could probably synthesize this global-as-parameter method implicitly.
We could internally translate this:
probe begin { println(@1, $2) }
into this:
global __string_arg1 = ""
global __long_arg2 = 0
probe begin { println(__string_arg1, __long_arg2) }
with a matching staprun call to pass the module parameters. This would
avoid recompilation for a lot of parameter use-cases.
Josh