Re: Output Redesign in SystemTap Runtime

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

Hi -


On Wed, Apr 27, 2005 at 09:38:18AM -0700, Martin Hunt wrote:

> [...] The whole point of my proposal was about tagging data.  [...]
> as a minimum, I am trying to do deferred symbolic lookups on
> addresses, primarily in stack data.

I think it is a mistake to mix up solving the deferred decoding
problem with a transport layer discussion.  It would help to have a
precise problem statement for deferred decoding.  Is it that it simply
takes too long to do it within a normal probe?  (How long is it
really?  Could it be done in an "end" probe instead, which needs no
tight time constraints?)  Or is it that the resulting string could be
too long?  (Then do we need to calibrate our hypothetical
string-length limits?)  Or is it some more theoretical problem like
having enough information in the kernel module to deal with user-level
addresses in the future?


> I'm asserting:
> 1. tags would be really useful.

To make this argument you really need to work it out a little more.
Who would generate the tags?  Who would use them?  What are the
alternatives?  What problems do they solve?  What software interface
layers does it define?

> 2. If we implement them right, they will be safe to use for
> timestamps too.

By "use for timestamps" are you referring to the more general problem
of packetizing or enveloping a trace message coming from a probe, so
that it can be interleaved to mesh with similar records from other
CPUs?  If so, deal with only that problem.  For example, decide
whether it's important to chunk multiple trace messages coming from a
given probe handler run into one unit, or whether the interleaving
granularity can be per-script-functioncall.


- FChE

Attachment: pgp00000.pgp
Description: PGP signature