This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: systemtap/pcp integration
- From: fche at redhat dot com (Frank Ch. Eigler)
- To: Nathan Scott <nathans at redhat dot com>
- Cc: David Smith <dsmith at redhat dot com>, pcp at oss dot sgi dot com, Systemtap List <systemtap at sourceware dot org>
- Date: Mon, 21 Jul 2014 22:57:27 -0400
- Subject: Re: systemtap/pcp integration
- Authentication-results: sourceware.org; auth=none
- References: <53C83CB9 dot 3020808 at redhat dot com> <861139755 dot 14608867 dot 1405992742567 dot JavaMail dot zimbra at redhat dot com>
Hi, Nathan -
nathans wrote:
> [...]
> (OOC, what's {MODULE_NAME} in this context?)
It is usually a machine-generated unique identifier for the systemtap
script in question, such as "stap_deadbeefdeadbeefdeadbeef_2222". It
is not generally predictable in advance. (A user can override the
name, but that costs possible collisions.)
> [...] PMDA is written to be able to detect arrival/departure of new
> MMV files based on changes in a directory (and the location of that
> directory is parameterised via /etc/pcp.conf variables). [...]
If we do end up sticking with this MMV approach, the PMDA would
probably need to use glob(3) or similar to search for
"/proc/systemtap/*/mmv" instead of "/proc/mmv/*".
> It also occurs to me that there's not really anything
> systemtap-specific about the kernel MMV instrumentation you've done,
> or is there? [...] It would be worth thinking about if the MMV
> bits in your script could become a more general kernel module for
> others to use too [...]
Yes, perhaps, though the path of code implementing a seemingly good
idea into the kernel is rarely smooth. They generally dislike
infrastructure unless it's well-yearned-for. So, if you wish to
pursue this goal, some serious selling on LKML will be needed.
- FChE