RE: command line arguments

RE: command line arguments

[Stone, Joshua I]

Frank Ch. Eigler wrote:
> Hi -
> 
> I committed a draft of command line argument support as per bug #1304.
> One part (plain substitution into scripts) is usable now.  Another
> part (initializing globals at module init time) is sort of dormant.
> 
> The way the first part works is by making any additional arguments
> passed to "stap" available to the script for substitution as string
> or number literals:
> 
> # stap -e 'probe kernel.function(@1) { print($2) }' sys_open 4

Very cool!
 
> The @ vs $ distinction encodes whether the numbered argument should be
> pasted as a string or number literal.  I considered guessing but
> heuristics don't seem to belong somewhere so critical.
> 
> I'm open to suggestions about better notation than $n and @n.  (#n is
> out because of comments; % and others because of arithmetic
> operators.) 

It would indeed be nice if $N could be dynamically be typed, especially
since the other $target variables are, but I can see how this would be
hard.

The @ is ok, but it doesn't really say "string" to me.  Perhaps a
single-quote or backquote might be better - '1 or `1?

Another option is to allow expansion of $N within string literals - then
if you want a string you use "$N" and for a number use just a plain $N.
Then your toy command-line would be:

# stap -e 'probe kernel.function("$1") { print($2) }' sys_open 4

And you could still do error checking...

# stap -e 'probe kernel.function("$1") { print($2) }' sys_open foo
ERROR: got a string argument where a number was expected (argument 2)


Josh

Re: command line arguments

[Frank Ch. Eigler]

Hi -

> It would indeed be nice if $N could be dynamically be typed, especially
> since the other $target variables are, but I can see how this would be
> hard.

That's the heuristic I was talking about.  One problem is that several
places like probe point functors (.statement(), .function()) accept
*both* string or number literals.

> The @ is ok, but it doesn't really say "string" to me.  Perhaps a
> single-quote or backquote might be better - '1 or `1?

Or perhaps a backslash, as in regexps.

> Another option is to allow expansion of $N within string literals [...]
> # stap -e 'probe kernel.function("$1") { print($2) }' sys_open 4

But then normal dollar signs would have to be quoted.

- FChE

command line arguments

[Frank Ch. Eigler]

Hi -

I committed a draft of command line argument support as per bug #1304.
One part (plain substitution into scripts) is usable now.  Another
part (initializing globals at module init time) is sort of dormant.

The way the first part works is by making any additional arguments 
passed to "stap" available to the script for substitution as string
or number literals:

# stap -e 'probe kernel.function(@1) { print($2) }' sys_open 4

The @ vs $ distinction encodes whether the numbered argument should be
pasted as a string or number literal.  I considered guessing but
heuristics don't seem to belong somewhere so critical.

I'm open to suggestions about better notation than $n and @n.  (#n is
out because of comments; % and others because of arithmetic operators.)

- FChE

Re: command line arguments

[Martin Hunt]

On Thu, 2006-02-23 at 17:42 -0500, Frank Ch. Eigler wrote:

> # stap -e 'probe kernel.function(@1) { print($2) }' sys_open 4
> 
> The @ vs $ distinction encodes whether the numbered argument should be
> pasted as a string or number literal.  I considered guessing but
> heuristics don't seem to belong somewhere so critical.

Why not do things the standard way and just pass all the args in as
strings? 

Encoding the type in the args makes the command line very inflexible. No
way to do variable args. No way to do standard options, etc. 

Martin

Re: command line arguments

[Frank Ch. Eigler]

Hi -

hunt wrote:
> [...]
> Why not do things the standard way and just pass all the args in as
> strings? 

Because then they cannot substitute for numeric literals, such as
parameters to probe point functors, histogram parameters.

> Encoding the type in the args makes the command line very inflexible. 
> No way to do variable args. No way to do standard options, etc. 

How so?  If you want to look at them as strings, only refer to
@1....@NNN.


- FChE

Re: command line arguments

[Martin Hunt]

On Fri, 2006-02-24 at 07:24 -0500, Frank Ch. Eigler wrote:

> How so?  If you want to look at them as strings, only refer to
> @1....@NNN.

Ah, I see. I was confused because this doesn't work:

> stap -e 'probe begin {printf("%d (%s)\n", $1,@1);exit()}' hello
parse error: number invalid or out of range
        saw: number 'hello' at <input>:1:41

And this doesn't work

> stap -e 'probe begin {printf("%d (%s)\n", $1,@1,$2,@2);exit()}' 42
parse error: command line argument index invalid or out of range
        saw: operator ',' at <input>:1:39

But, at least this does...

> stap -e 'probe begin {printf("%d (%s)\n", $1,@1);exit()}' 42
42 (42)

Still, I don't see how you can do anything like getopt to process args.
I see in a later message you are thinking of having some special syntax
to allow variables to be set on the command line?  I'd like to see some
real example of how this is supposed to work .

I'd like to see this kind of parsing be possible. How would it work?
> topsys.stp -- -d 5 -n 20
> topsys.stp -- -n 20 -pid 5160,5161
> topsys.stp -- -d 5 -name "metacity"

Re: command line arguments

[Frank Ch. Eigler]

Hi -

hunt wrote:

> Ah, I see. I was confused because this doesn't work:
> > stap -e 'probe begin {printf("%d (%s)\n", $1,@1);exit()}' hello
> [...]
> > stap -e 'probe begin {printf("%d (%s)\n", $1,@1,$2,@2);exit()}' 42

Yes, both these intentionally emit errors.

> [...]  Still, I don't see how you can do anything like getopt to
> process args.

One can't, with what there is now.  It would not take much to add
another way of accessing the entire argument array, for some
adventurous person to implement getopt on top of.

Then again, I wonder how great a loss not bothering would be.  Few
shell scripts use getopt.  Large ones, sure, but little ones almost
never.  I imagine systemtap scripts to be more like the small ones,
using plain positional arguments.


> I see in a later message you are thinking of having some special
> syntax to allow variables to be set on the command line?  [...]

Code is now there in stpd and in the probe modules to initialize
number and string globals, by simply giving them as additional named
module options ("insmod foo.ko foo=1 bar=beef").  There is no stap
interface to that yet.  I figured I'd hold off on that part until the
cross-instrumentation (=.ko-precompilation) problem is solved.


> I'd like to see this kind of parsing be possible. How would it work?
> > topsys.stp -- -d 5 -n 20
> > topsys.stp -- -n 20 -pid 5160,5161
> > topsys.stp -- -d 5 -name "metacity"

For something that elaborate, in the absence of other facilities, you
can use a shell/perl/tcl wrapper.


- FChE

Re: command line arguments

[Martin Hunt]

It seems to me that this feature is being created from the bottom up. I
think we really need to consider how this should work and then figure
out how to do the internal magic to make it happen.

For example,
> stap foo.stp -- args
> foo.stp args

For modules:
> stap -mfoo foo.stp -- args 
> stap foo.ko -- args

Now, there is a sticky problem caused by the fact that stap compiles and
executes a program at the same time. Users may want to pass in the name
of functions to probe, and those must be fixed at compile (elaboration)
time.  Using -D to set those seems like a reasonable approach.
> stap -Dprobe1="sys_open" foo.stp -- args

The script would then do
probe kernel.function("$probe1") { ... }

That would require a change to our current definition of "-D". While we
are discussing these issues, it would be nice if we can change at least
MAXSTRINGLEN and MAXMAPENTRIES to variables so they can be changed at
module load time.

> > [...]  Still, I don't see how you can do anything like getopt to
> > process args.
> 
> One can't, with what there is now.  It would not take much to add
> another way of accessing the entire argument array, for some
> adventurous person to implement getopt on top of.

In fact, all it takes is some way to let the script know how many args
were passed in; something that basic error checking should also make
necessary.

So, for 'n' args, setting @(n+1) = ""  OR creating $argn and setting
that to 'n'.

Re: command line arguments

[Daniel P. Berrange]

On Thu, Feb 23, 2006 at 05:42:18PM -0500, Frank Ch. Eigler wrote:
> Hi -
> 
> I committed a draft of command line argument support as per bug #1304.
> One part (plain substitution into scripts) is usable now.  Another
> part (initializing globals at module init time) is sort of dormant.
> 
> The way the first part works is by making any additional arguments 
> passed to "stap" available to the script for substitution as string
> or number literals:
> 
> # stap -e 'probe kernel.function(@1) { print($2) }' sys_open 4
> 
> The @ vs $ distinction encodes whether the numbered argument should be
> pasted as a string or number literal.  I considered guessing but
> heuristics don't seem to belong somewhere so critical.
> 
> I'm open to suggestions about better notation than $n and @n.  (#n is
> out because of comments; % and others because of arithmetic operators.)

The scenarios I'd like to use command line args in, are for tweaking
aspects of the data capture, say, sampling rate of a timer, or if I
was probing 'sys_read', some variable to control how often to log.
So I'd think named arguments would be clearer to use, possibly to set 
global variables. So for example

    global samplerate = 1000

    probe timer.jiffies(samplerate) {
       ...
    }

One could tweak the rate with

  # stap --define samplerate=50  stuff.stp

Or another exaple, if one wanted to watch all file opens under a particular
directory

    global prefix = "/"

    probe kernel.function("sys_open") {
      if ( isinstr(prefix, substr(user_string(filename),0,strlen(prefix)) ) {
         print("Pid " . pid() . " opens " . user_strin(filename))
      }
    }

Then one could restrict it to just files under /etc with

    # stap -D prefix=/etc  watchopen.stp

Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 

Re: command line arguments

[Frank Ch. Eigler]

Hi -

> [...] So I'd think named arguments would be clearer to use [...]
>     global samplerate = 1000
>     probe timer.jiffies(samplerate) [...]

One side problem with this is that probe point specifications only
take literals as arguments, since they are evaluated at translation
time.  Ordinary globals can change their value.  (While one might
imagine a way of making this work for timers, it won't for dwarf-type
probes.)  To support default literals in the absence of command line
args, we could conceivably support shell-style ${1-default} type
bracketing.

Initializing globals by name is something that the other ("dormant",
module-params-based) part of the command line argument code is
designed to enable.  That part should serve most of your purposes,
once it's finished.  Note that we currently lack syntax to initialize
globals within script ("global foo = LITERAL") but that's coming too.

It is indeed a little odd to have this dichotomy between two types of
parametrization, but then again, C has that too (cc -D vs. getopt).

- FChE

Re: command line arguments

[Roland McGrath]

An idea that occurred to me is to have command-line arguments be like
systemtap function arguments.  For example:

global s, n
probe begin (name: string, number: int) { s = name; n = number; }

stap foo.stp foobar 123

Re: command line arguments

[Frank Ch. Eigler]

Hi -

roland wrote:

> An idea that occurred to me is to have command-line arguments be like
> systemtap function arguments. [...]
> 
> global s, n
> probe begin (name: string, number: int) { s = name; n = number; }
> stap foo.stp foobar 123

With the current code, this would look thus:

# global s, n
# probe begin { s = @1; n = $2; }
# stap foo.stp foobar 123

Since the "number" and "name" names aren't being used at the command
line, there seems to be little loss.

(There are other complications with parametrizing the "begin"
probe.  For one, there can be many begin probes. :-)

- FChE