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]

RE: Output Redesign in SystemTap Runtime


I'm not following all of this discussion, but it
appears to me that some people would really want
tagged data, and some people would not (Frank and
Martin being living examples) and that it would
be best if the system had the flexibility to serve
both. Can we structure the system to let our users 
choose?

Brad

-----Original Message-----
From: systemtap-owner@sources.redhat.com
[mailto:systemtap-owner@sources.redhat.com] On Behalf Of Frank Ch.
Eigler
Sent: Wednesday, April 27, 2005 10:21 AM
To: Martin Hunt
Cc: systemtap@sources.redhat.com
Subject: Re: Output Redesign in SystemTap Runtime

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]