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

["Chen, Brad" <brad dot chen at intel dot com>]

I think I now finally grasp the difference between the 
"provider" programming model and the script library. The 
former creates new namespace of events for which handlers 
can be defined (like DTrace) and the later defines a new 
data and/or procedural API.

Event-based profiling providers will generally require a
kernel module in C. There are a couple reasons:
- The hardware resources in question are scarce and
  should support cooperative allocation with other
  programs such as OProfile, perfmon, perfctr and
  other future profilers which aren't Systemtap-based.
- Manipulating the event counter state requires use
  of priviledged instructions and CPU model-dependent
  constants that we might prefer to isolate in 
  machine-dependent modules. I am assuming we'd prefer
  to encourage scripts to be portable. 
It's dangerous to think about this as a special case. We
know about many kinds of hardware changes that could lead
to similarly constrained resources. For example:
- power management hardware
- virtualization technologies
- strange new hardware to support multicore architectures
We know this stuff is coming, but I don't think we understand 
the implications. It seems safe to assume existing language
systems would be extended to accommodate these, and less safe
to assume we could design our new language to support these
and track them as they develop.

Brad

-----Original Message-----
From: systemtap-owner@sources.redhat.com
[mailto:systemtap-owner@sources.redhat.com] On Behalf Of Frank Ch.
Eigler
Sent: Wednesday, April 06, 2005 9:58 AM
To: Chen, Brad
Cc: systemtap@sources.redhat.com
Subject: 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