corrected: tapset/script information template

["Frank Ch. Eigler" <fche at redhat dot com>]

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