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: Better handling of arguments/literals from the command-line?


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


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