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

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

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