This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: command line arguments
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'.