Re: Output Redesign in SystemTap Runtime

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

Hi -

hunt wrote:
> [...]
> > > Not really.  "<stack> 0xf0001234 ...  </stack>" gets saved as a string
> > > [...]
> > 
> > OK, that's the sort of "heroic measure" I was talking about.  So now
> > we have a string that has some self-descriptive content markup.
> 
> I don't understand what is heroic about it. Or what the problem is. Do
> you have an example? [...]

I'm finding it hard to not be so abstract about it.  My problem is
that you are proposing to add content-type specific tracing code to
the lower layer, somehow to make your packetization work easier or
something.  (You mentioned adding tags for stack traces, registers,
other stuff.)  You are mixing two distinct layers, two distinct jobs.

It does not sound bad to have stack-query or other state-query
functions in the runtime, which when called from script, return
somewhat self-describing blobs.  Perhaps the systemtap driver's
output-formatter widget can look for these self-describing tags and do
something useful (decode) them.

But it's not logical to *also* use such a tagging idea as something
necessary for a *transport layer* issue such as packetizing and then
stitching relayfs data.  You even mentioned binary encoding for some
types (tags?) of strings, as if those tags could be interpreted to
guarantee something (ascii vanilla numericity?)  about the content.

You must solve the transport layer's problems in a way that it is not
sensitive to the content of the strings/numbers being sent through it.
For example, the transport layer must tolerate a user happening to
print a string such as "</text><entry /><text>" (this would break your
"<entry/><text>....</text>" enveloping.

Does this make my concern more clear?

- FChE

Attachment: pgp00000.pgp
Description: PGP signature