This is the mail archive of the
systemtap@sources.redhat.com
mailing list for the systemtap project.
Re: Some notes on translation
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