This is the mail archive of the
systemtap@sources.redhat.com
mailing list for the systemtap project.
corrected: tapset/script information template
- From: "Frank Ch. Eigler" <fche at redhat dot com>
- To: systemtap at sources dot redhat dot com
- Date: Thu, 14 Apr 2005 20:54:09 -0400
- Subject: corrected: tapset/script information template
Hi -
Sorry, an early draft went out by mistake. Try this instead:
In order to organize and collect the various application areas for
systemtap and its extension "tapsets", I propose filling in this
template, and committing it to a new directory within the CVS
repository. The template is meant to cover tapset widgets as well as
just ideas for end-user scripts that may need some unspecified sources
of data. At least it's a way of organizing and archiving little
snippets of ideas and code. I will commit a few instantiations soon
to start off.
At the beginning, these tapset descriptions would just serve as
repository of ideas, to inform the implementors about requirements.
Over time, as the system starts to run, the description directories
can come to include real runnable code, test cases, documentation.
* Application name:
* Contact:
(Give a name and contact for this tapset/script description.)
* Motivation:
(Identify need: "known customer problem", "sysadmin curiosity",
"design exploration", "matching dtrace/dprobes/... demo")
* Background:
(Identify any personal experience in the motivated area, so that
the rest of the data may be viewed as first-hand vs. indirect
knowledge.)
* Target software:
(Identify the "kernel" and subsystems, or "user" and programs, or both)
* Type of description:
(Identify "tapset" or "end-user script" or both. If tapset,
identify needed extension points according to current taxonomy.)
* Interesting probe points:
(Identify possible types of probe points within target software.
If a tapset, suggest probe point specifications to identify them
in user scripts. Identify possible probe-management APIs.)
* Interesting values:
(Identify data structures within target software that a user script
may find interesting. Identify those values that may be so commonly
used that the translator should map abbreviation macros to them.
Classify values as consumed from lower level vs. provided to higher
level.)
* Dependencies:
(Identify any prerequisites needed to make this useful, such as
additional kernel drivers, processing tools, data files,
hardware types and resources, minimum performance, configuration
details.)
* Restrictions:
(Describe any conflicts making this useless, such as other running
tools, limitations, unfortunate configuration defaults, political
obstructions.)
* Data collection:
(Outline the suggested event-handling / data-collection control flow,
to gather appropriate abstracted / aggregated / derived data.)
* Data presentation:
(Outline how the collected data should be presented to the user, whether
any particular data transfer mechanism is uniquely suitable, how the data
it may be post-processed to make it more useful.)
* Competition:
(How do other systems deal with similar target areas?)
* Cross-references:
(Identify any other tapset/script descriptions in the repository
that relate to this one. Add relevant web URLs, paper references,
contact info for related R&D groups.)
* Associated files:
(Store as many illustrative files as possible beside this
description. Identify each's type (systemtap script, j/kprobes
source, pseudocode, dtrace script, working / draft, web page
snapshot, etc.) Identify origins.)
- FChE