This is the mail archive of the systemtap@sources.redhat.com mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Some notes on translation


Martin Hunt writes:
 > 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.

OK, I certainly don't want to duplicate anything you were working on
or were planning to work on.  Is there anything in what I've outlined
that isn't already being covered by you or Frank or Will (or someone
else on the list)?  If not, that's fine - I can easily find something
else to work on...

[...]
 > 
 > > 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.

That's also what I've heard - all the more reason to start now.  This
could be a tiny first step toward the much-desired dwarf2 library.

 > 
 > > 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.  

I was thinking that the netlink API I proposed in the parent post
should be able to cater to all of systemtap's needs - what happens to
the data once it gets to userspace is up to the application (print to
stdout, save to file, etc...).  The actual API and protocol need more
thought, but the design goal would be to have a simple API that hides
the details of the underlying implementation as well as modalities for
at least the user side e.g. packet vs high-bandwitch vs /proc.  I'm
not sure why we'd want to use /proc in place of netlink in any case -
also I thought putting new stuff in /proc was discouraged anyway.

Thanks,

Tom


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]