This is the mail archive of the systemtap@sources.redhat.com mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

tapset taxonomy


Hi -


Here is my attempt to put into words an insight from today's call.
The core issue is extensibility: how to extend the reach of systemtap
script into the target software.  This reach can be some combination
of data access and function calling.

Extensibility can occur within the library, within the language, or
within the translator.  Their nature and availability has implications
for safety, utility, and tapset authorship.

Library extensibility refers to the availability of a library of
script fragments, which build upon existing language/translator
mechanisms to build abstractions for end-user scripts.  These
effectively abbreviate the user script, and provide no extra
expressivity. [***]

Language extensibility may be an syntactic embedding mechanism within
the scripting language, like explicit C code in yacc grammars, or like
in dpcc's expression strings.  If the translator passes such
constructs through, then script authors might get approximately the
same unconstrained expressive power as someone writing C code.
Naturally, such power would be left to "guru-mode" users and to
privileged script "tapsets" located in a library.

Translator extensibility may occur by some mixture of translator
changes, such as recognizing additional probe-point specifications,
automagically providing synthetic variable/function declarations to
user scripts.  Since these all involve changes to the translator, they
naturally enable the extension author to emit arbitrary lower-level C
code to enable the higher-level additions.  In this case, the script
user doesn't have any extra syntax, and is constrained to touch only
whatever data the translator modifications deemed fit.  The emitted
lower-level C code could make use of just the base kernel.  Or it
could refer to additional kernel modules, and maybe even extra local
libraries, as the extension author sees fit.  These additional kernel
modules or libraries don't need a-priori fixed APIs, since the
modified translator can talk to them on their own terms. [***]

One variant of this may occur by a plug-in interface that allows
someone to load new modules into the translator.  If pursued, this
mode could allow extension along the above lines, but without
requiring translator source code changes.

Another variant of this constitutes a middle road between language and
translator extensibility: debug-info processing.  The translator can
grok the dwarf debug-info of modules relevant to given probe-points,
and can provide constructs (probably function declarations) to the
scripts to traverse them.  This should give around the same
expressivity as the gdb/dpcc style has, but with more generality,
language-neutrality, control and (sadly) probably wordy
verbosity. [***]


So, where does all this leave "tapset" authors?  Each will decide
which of the available points of extensibility they must exploit in
order to expediently expose their excellent expertise.  Some may
settle for vanilla script libraries only.  Those needing to interact
with future peculiar chunks of kernel (e.g., Brad's list of future
instrumentables) likely need to emit strange new C code to talk to
them, so need language and/or translator extensibility.

In order to let us decide how many of these extensibility points we
need to support, we need ... drumroll ... more detailed examples.  My
intuition says that the basic library and translator points I marked
above with [***] are sufficient for the forseeable future.


- FChE


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]