This is the mail archive of the
systemtap@sources.redhat.com
mailing list for the systemtap project.
Re: comments from prospective VM tapset author
- From: fche at redhat dot com (Frank Ch. Eigler)
- To: Jim Keniston <jkenisto at us dot ibm dot com>
- Cc: SystemTAP <systemtap at sources dot redhat dot com>
- Date: 09 May 2005 11:44:08 -0400
- Subject: Re: comments from prospective VM tapset author
- References: <1115248527.3433.6.camel@dyn9047018078.beaverton.ibm.com>
jkenisto wrote:
> Here are notes from conversations with Darren Hart, who is working
> on VM instrumentation that we hope will lead to a tapset. [...]
Thank you. Such information is valuable.
> [...] Darren has been using kprobes and jprobes [...] [...] -
> Instrumentation is a library of functions [collecting] an advertised
> set of values [...] A SystemTap-generated handler would call such a
> function to obtain the advertised values.
There is mixing of active (probing, servicing callbacks from kprobes)
and passive (value gathering, servicing calls from systemtap/runtime)
elements here. There is likewise a mixing of the concept of
"instrumentation", both as self-contained end-user program versus as a
tapset/extension for use by a higher level script.
It would be good to break apart these aspects somehow, so that one can
contemplate implementation options separately. For example, when
Darren wants "how many pages requested / freed to get them", does he
mean that these numbers are available in the kernel, just need
exposure to a user-level script for printing? OK, then where exactly
can those numbers be found today? Or do the numbers have to be
computed indirectly, perhaps via some active probes? How?
> [...][Re. the tapset template]
> - "Seems like a lot. Who fills it out? Who reads it?"
The idea is for domain experts or friends to record the information.
For example, it is a place to put pseudocode that gathers information
from low-level data structures, for data which could ultimately end up
as systemtap variables. It is read by people who want to write
tapsets to implement the extensions, or the end-user scripts to call
them.
In some cases, an end-user may only know that some kinds of
information is required, but not know how to find that within the
kernel. Thus only the "end-user" portions of the template might be
filled in, awaiting for someone to figure out how to provide that
information within a tapset.
> - Background should be combined with Motivation.
> - Target software should be obvious from Motivation/Background.
> - Interesting values, Data collection, and Data presentation should be
> combined.
I'm sure the template will evolve as more examples come about.
I'll assemble one or two based upon Darren's text.
- FChE