This is the mail archive of the
systemtap@sources.redhat.com
mailing list for the systemtap project.
RE: what is a tapset? [RE: Skeleton detailed design document]
- From: "Chen, Brad" <brad dot chen at intel dot com>
- To: "Frank Ch. Eigler" <fche at redhat dot com>
- Cc: <systemtap at sources dot redhat dot com>
- Date: Mon, 4 Apr 2005 16:36:34 -0700
- Subject: RE: what is a tapset? [RE: Skeleton detailed design document]
A couple issues/questions occurred to me around the
notion that tapset implementations would consist solely
of script code and could not use C code:
- DTrace is quite deliberate about separating script
authorship from provider authorship. I don't know if
providers are implemented in C or D, but it seems
their intent from the DTrace documentation that script
and provider implementations do not mix. What is our
intent for Systemtap? Suppose we wanted to discourage
mixing of script and tapset implementation. Does this
impact the languages and language constructs used to
write tapsets?
My preference: following the DTrace lead, encourage/force
tapsets to be defined separately from Systemtap scripts.
- Portable scripts. To what degree do we want to
encourage portability of Systemtap scripts across
different instruction sets? What script language
constructs do we need to include or exclude to
meet portability goals? ASM code escapes in
script are an example of a construct that would
discourage portability. Presenting all tapset APIs
in a single machine-independent directory is an
example of a mechanism for forcing portability.
My preference: Isolate machine dependent code in
tapset implementations by excluding features from
the script langauge that expose machine dependent
features.
Brad
-----Original Message-----
From: systemtap-owner@sources.redhat.com
[mailto:systemtap-owner@sources.redhat.com] On Behalf Of Frank Ch.
Eigler
Sent: Friday, April 01, 2005 1:01 PM
To: systemtap@sources.redhat.com
Subject: Re: what is a tapset? [RE: Skeleton detailed design document]
Hi -
On Fri, Apr 01, 2005 at 12:18:47PM -0800, Chen, Brad wrote:
> [...]. Perhaps this is overly simplistic; is any of this
> incorrect? What parts are missing?
Looks okay, except that I am not sure that the "tapset" constructs
I've seen so far need *any* C code (custom headers or libraries). I
would like to see whether "tapsets" can be restricted entirely to live
within script fragments that the elaboration phase would pull in.
By the way, the kernel symbolic information would be under
/usr/lib/debug or /usr/src/debug, whereever kernel-debuginfo RPMs
deposit their goods.
> [...]
> Question: Can two taps "mytap1.ko" and "mytap2.ko" be loaded
> in the kernel at the same time?
Concurrent independent systemtap runs should not be precluded.
> If so, do they need to share anything besides kprobes?
So far, no. However, when it comes to sharing other resources such as
the perfctr bits, some arbitration code will have to be written into
the runtime.
> [...]
> - Do the tapset libraries need to be built with the kernel?
> [yes; they will reference kernel symbols that must be
> resolved statically]
(That depends on whether "tapset libraries" are needed at all,
and what form they take if so.)
> - I believe kernel symbolic info will be needed during the
> compile of the elaborated script to deal with kernel data.
Yes, except perhaps for those simple cases where the plain
ELF/ksymlist symbol tables are sufficient for the purposes of a probe.
> - Can a script refer directly to a kernel code symbol,
> or can it only do so via a tapset?
If by "refer" you mean in a probe point, i.e.,
probe kernel.function("foo") { ... }
then I envision no elaborate "tapset" being necessarily involved
in all such references. The systemtap translator would have
built-in support for a slew of probe point specifications. This
one would be implemented by symbol table or debug info reading.
> It might be nice if jprobes were responsible for most/all
> resolution of kernel symbolic info.
jprobes by its nature can't do anything symbolic.
Data access works by textual "coincidence" of signatures.
Perhaps you need to elaborate.
> - Systemtap scripts ought generally to be portable. Is there
> any hope of making a mytap.ko that is portable across kernel
> builds and configurations? [...]
I see little hope, especially with modversions and other
configuration sources of incompatibility (e.g. SMP).
- FChE