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]

Re: what is a tapset? [RE: Skeleton detailed design document]


Hi -


On Wed, Apr 06, 2005 at 08:43:09AM -0700, Chen, Brad wrote:
> [...]
> > Remember my references to a "script library"?  Would such a library of
> > scripts, each of might define a higher-level probing interface, be
> > sufficiently separate from end-user probe scripts for your taste?
>
> [...]  library author has different language facilities than the the
> script author, such that the script library author can define a new
> tapset and the script author cannot. [...]

One candidate for language differences is the possible enablement of
embedded-C or less expressive debuginfo-traversal operations in
guru-mode script libraries.  But you're right, this is all very
fluffy.


> I would agree that we should be in a better position to make a good
> decision when we have more working code. I think one alternative to
> the script library is fairly clear; tapset definitions in C.

OK.  I think we still lack a definition of "tapset", and this is
helping cloud the conversation.

One way to think of a "tapset" is as code that provides a new
probe-point namespace.  A probe defined with a probe-point in that
space would be able to have some sort of special breakpoint- or
event-registration code output in the translation; it would make some
special set of variables available to the probe body script.  In this
view, the enumeration of probe-point syntax examples in src/TODO
corresponds to a small handful of "tapsets", support for each of which
could be hard-coded in C++ within the systemtap translator.

Note that since the translator can emit an arbitrary amount of code,
additional external C code in the form of runtime libraries may not be
needed at all.  This is why I've asked whether supporting performance
counter events as a probe point would require some external module to
arbitrate the resources, or else whether the translator can emit
management directly within its own output.

This type of tapset naturally involves modifying the translator.  To
what extent would this be unacceptable?  What kinds of tapset of this
category might third parties want to write in the future?


A quite different way to think of a "tapset" is something other than
additional probe-point syntaxes.  This could be like what I described
in <http://sourceware.org/ml/systemtap/2005-q1/msg00268.html>.  This
sort of tapset likely requires no C code, embedded or otherwise.


- FChE

Attachment: pgp00000.pgp
Description: PGP signature


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