Re: Some notes on translation

[Martin Hunt <hunt at redhat dot com>]

On Thu, 2005-02-24 at 17:41 -0600, Tom Zanussi wrote:
> Tom Zanussi writes:
>  > Hi,
>  > 
>  > I've been thinking about what work needs to be done on the user side
>  > of systemtap, more specifically about things that correspond to the
>  > translation phase and bits of the execution and output phases.  To
> 
> What I'd like to do is start implementing or at least prototyping some
> of this stuff, but it would be good to know first if anyone else is
> working on any of these things yet.  

I am working on a new prototype, but I haven't made much progress
lately, other than working on the runtime. Next week I plan to start
focusing on the prototype so I can have something to test the runtime.

> I missed the first part of the
> systemtap call this morning, so I didn't get to hear about any status
> on things like the runtime library, which I'd like to start using (and
> which I'd be happy to add things to if needed).

Great!  I have all the hash table stuff done, plus  some other pieces
are in various states.  It needs some cleanup. I'll try to get a
snapshot checked in by  Monday so others can hack on it.

I think as we pull together all the pieces (parser, translation,
runtime, boilerplate, providers (tap sets?) we'll think of a lot more
that needs to be in the runtime library. 

> What I'm thinking of doing is hand-coding a functional kprobe handler
> (not using jprobes) that would look something like what would be
> output from the translation phase, probably a variation on one of the
> probes I outlined here.  It would use dwarf2 information to access the
> probed function parameters (I'd have to do some reading of the dwarf2
> spec but it shouldn't be a big deal to do something simple like figure
> out where an int parameter is for instance), 

In my experience DWARF2 is not as easy to use as it should be.

> and use whatever's
> available (or easy to add) from the runtime library to do something
> useful in the handler.  The boilerplate probe
> registration/deregistration code would be auto-generated.  I would
> also implement the kernel->user/user->kernel netlink protocol and API
> - since I've already written code to do similar things, this is
> relatively low-hanging fruit - and would use it to print() from the
> probe and have the user space program request and print data items
> from the probe.  I'd also create a userspace library called taplib
> which I'd stick the userside API implementation into.  Finally, I'd
> write a simple systemtap command that just hangs around printing
> whatever it gets from the netlink socket and requesting and printing
> the results when Control-C is pressed to end the session.

For output, I was planning on eventually supporting 3 different methods.
One would be like you describe above; print using netlink. That would be
the default. Another method (which Frank proposed) would use a /proc
interface to allow polling of statistics.  And there would be some way
to use netlink to dump high-bandwidth data to a file to be processed
later.  I haven't thought much about that yet.  

Martin