[RFC] Framework for easy distribution of SystemTap scripts (V3)

[Anithra P Janakiraman]

Hi Frank,

Thanks again, attaching a V3

Regards,
Anithra.


On 04/09/2010 10:09 PM, Frank Ch. Eigler wrote:


>>
>> We have placed the script in the scripts directory, We dont want to
>> install the script, so didn't see the use for a man page.
>
> Why *not* install it?  How are people supposed to get a hold of your
> script if it doesn't get installed?

This script will be used by a very select set of users - say admins who 
wish to debug a customer machine, dont think it would be right to 
install it as part of the systemtap/systemtap-runtime rpms as it is not 
going to be used by the 'regular' stap user. It can be obtained from the 
source.


>>>> +A post processing script can be provided using the -p option.
>>>
>>> You should specify what exactly this means.  A '/bin/sh -c' command
>>> line to pipe stdout through?
>>
>> The post processing script can do anything the administrator creating
>> the package wishes to do, maybe even fwd the output to a support team,
>> or provide suggestions based on the output. Have added an explanation.
>
> The key part is to say that for -p SCRIPT, SCRIPT is actually a file name,
> whose contents will be copied into the new package, and which will be run
> via a pipe to consume the stdout of stdrun.

Done. Changed!

>
>>>> +        *)                     STAP_OPTIONS=$@
>>>> +				echo $STAP_OPTIONS
>>>
>>> You'll need to watch the quoting in these $foo variables.
>>> They could contain spaces etc.
>>
>> Didn't understand the comment. stap-buildpkg script.stp -n "package
>> name" -v 1  would work.
>
> Yes, but you need to check your quotation throughout.  In some cases,
> there is "$foo", and in other cases, only $foo.  The difference can
> matter in some contexts.  So I'm just saying to check and/or test with
> all possible spacey arguments.

Done.

>
>
>>> FWIW, you could include this template within the main buildpkg script, as
>>> in
>>>
>>> echo>   $PKG<<   'END'
>>> function run()
>>> ....
>>> END
>>>
>>
>> True. This is for simplicity of design. It is intuitively a template and
>> a separate file, so we decided to keep it like that esp since we had no
>> intentions of installing the build-pkg script.
>
> I guess simplicity is in the eye of the beholder.  You are having to
> edit the thing with sed and concatenate things before&  after: this
> too seems clumsy.

I agree that the sed part may not look very neat, but it is intuitive - 
we replace the place-holders in the template with their corresponding
values. I think it makes the package easier to understand. We can still 
change if you think it is absolutely necessary :)

>
>  From just eyeballing the new version of the scripts, it's not clear
> how this template file is located.  (If it were installed, you could
> autoconf and @prefix@-inform it.)
>

Assuming that the template file will be located in the same directory as 
the stap-buildpkg script, along with the README. Currently placed in the 
scripts dir.

>
>>>> +ps -ef | grep TEMPLATE_PKG_NAME | grep stapio | awk '{print $2}' | xargs
>>>> kill -SIGINT
>>>
>>> You wouldn't need this is you stored $! after the "staprun ...&" a few
>>> lines ago.
>>
>> Yes. We had done it this way keeping the older versions of SystemTap in
>> mind, the $! returns pid of 'staprun' in older versions. I've changed
>> the template
>
> (There still appears some ps -ef | grepping in the new version; probably
> all of that is unnecessary, if you save child pids properly.)

With the -start option, staprun executes in the background while the 
script exits. To stop users need to run the package with -stop, it would 
not be possible to store the child pids in this scenario.

>
>
>>> Why does this template need to exist?  The framework maker script
>>> could transcribe all of the options right into the output script.
>>
>> We want to provide a set of 'default' options.  [...]
>
> But one can provide defaults in lots of ways.  If you believe time-limited
> staprun execution is a common and basic option, you can make that an option
> provided first class within the stap-buildpkg script, and override it with
> a first-class command line options.
>
> To have a separate configuration file for this only, you'd need to
> argue why some options have to be treated differently from others.

The problem here is that we are not aware of the options or the no of 
options before hand. This would vary from script to script. The only 
option that we know would be always needed is 'time'. The config file is 
not used by the framework at all, it is needed only by the resulting 
package. Moreover each config option would be associated with a help 
text that can be appended to the resulting package' help text.

Regards,
Anithra.

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: distributionframework_v3.patch
URL: <http://sourceware.org/pipermail/systemtap/attachments/20100413/77d4b053/attachment.ksh>