This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: systemtap/pcp integration
- From: "Frank Ch. Eigler" <fche at redhat dot com>
- To: David Smith <dsmith at redhat dot com>
- Cc: Systemtap List <systemtap at sourceware dot org>, pcp <pcp at oss dot sgi dot com>
- Date: Tue, 22 Jul 2014 11:21:27 -0400
- Subject: Re: systemtap/pcp integration
- Authentication-results: sourceware.org; auth=none
- References: <53C83CB9 dot 3020808 at redhat dot com> <y0miomuk6qa dot fsf at fche dot csb> <53C94A6F dot 4080808 at redhat dot com> <20140718182751 dot GE20905 at redhat dot com> <53CE743E dot 9030807 at redhat dot com>
Hi, David -
> [...]
> I think a JSON fetcher/parser is a good idea.
Good enough to redirect from MMV?
> [...]
> > To spell it out, the idea was to encode the mmv format logic
> > (including metadata management) within a stap tapset script instead of
> > as C in the runtime. Then the C runtime would need to do nothing but
> > provide a memory-mapped-byte-array kind of abstraction, and a way for
> > the script code to read/write it (maybe a variant of
> > sprintf("%b...")?).
>
> Hmm. I think I see where you are going with this, but I don't know if it
> will work well for a couple of reasons. One is that you don't just write
> to this array, you have to be able to read it back (in order to shuffle
> things around, hook up instances to indoms, etc.).
(Not if the stap tapset just rewrites the whole metadata if necessary.)
> In addition, the best way to ensure that a client can read the data
> produced by the mmv stuff is to use the same header file so we know
> the data is laid out the same way.
Right ... though since MMV is a fixed ABI, a completely separate
implementation would help test the robustness of its specification.
- FChE