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

["Frank Ch. Eigler" <fche at redhat dot com>]

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

Attachment: pgp00000.pgp
Description: PGP signature