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: 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'.



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