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]

tapsets, Was Re: architecture paper draft


Hi -


Vara wrote:

> [...]  The main idea of a tapset as i see is, an expert in a given
> subsystem knows what is important to understand the inner workings
> of that subsystem. That expert will export such vital data in the
> form of a tapset using one or more functions that can be called from
> a probe. [...]  Tapsets just like probes can be either PC based or
> asynchronous timer based. [...]

So far, it sounds like your concept of "tapsets" could be subsumed
into the script library idea.  Specifically, a domain expert could
write some systemtap script fragments, as opposed to new C code that
somehow needs to find its way into the kernel.

Library script fragments would contain ordinary systemtap constructs
to define probes, functions, global variables needed to instrument a
target domain.  Each probe would use an already supported probe-point
syntax to identify a PC breakpoint or some other known event source.
Communication with the user-specified script would take place through
the globals and perhaps functions.

For example, a probe script fragment that specializes in the scheduler
could maintain a couple of global lookup tables that represent current
state in a higher-level way: like a list of currently running
processes, their cumulative run times, etc.  A user script referring
to these globals would automagically cause the related probes to be
activated.

We may encounter probe domains where the then-existing PC- or
event-based probe insertion APIs will not be not enough.  When that
time comes, I expect we will need to extend the systemtap translator
to support new probe-point constructs to refer to them.

It would be great if someone could work out an example or two to see
whether the idea of a script fragment library is or is not sufficient
to express interesting cases.


- 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]