pcp
[Top] [All Lists]

Re: systemtap/pcp integration

To: David Smith <dsmith@xxxxxxxxxx>
Subject: Re: systemtap/pcp integration
From: "Frank Ch. Eigler" <fche@xxxxxxxxxx>
Date: Tue, 22 Jul 2014 11:21:27 -0400
Cc: Systemtap List <systemtap@xxxxxxxxxxxxxx>, pcp <pcp@xxxxxxxxxxx>
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <53CE743E.9030807@xxxxxxxxxx>
References: <53C83CB9.3020808@xxxxxxxxxx> <y0miomuk6qa.fsf@xxxxxxxx> <53C94A6F.4080808@xxxxxxxxxx> <20140718182751.GE20905@xxxxxxxxxx> <53CE743E.9030807@xxxxxxxxxx>
User-agent: Mutt/1.4.2.2i
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

<Prev in Thread] Current Thread [Next in Thread>