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: architecture paper draft


Frank Ch. Eigler wrote:
Hi -


wcohen wrote:



Is there an advantage to splitting my_func_list from the probe body? Are there cases where my_func_list would be used more than once in the instrumentation? [...]


Indeed.

Actually, focusing on this particular aspect as a matter of grammar is
probably too narrow. If one class of provider is to identify breakpoints
using a namespace like "<provider>.<something>(<param>)", of which kernel.function("foo") or kernel.syscall("read") are two special cases,
then having explicit productions for these is not necessary. Think of
it more like on-the-fly nested struct declarations, to be resolved via
symbol tables during elaboration. The parse tree would look just like

As I was adding the providers to the grammar, they were starting to look more like generic symbols as you listed below. Having keywords for each provider didn't seem to be the way to go. So they are starting to look like the providers will be specialized declarations and then the probes will use the declarations. Okay that is a good reason to allow them to be separate.


What are the thoughts about the provider not being entirely static and having to do some work when the instrumentation is loaded, for example looking up the appropriate function address from a kernel data structure?


breakpoint_spec_component :=
"." symbol | "." symbol "(" argument_list ")"


The trick becomes the declaration of symbolic breakpoints as a script
fragment.  Imagine this file in the provider script library:

kern/2.6/syscall.stp:
   /* ... */
   break kernel.syscall.read = kernel.symbol("sys_read");
   break kernel.syscall.fork = kernel.symbol("do_fork");
   /* ... */

Then a user-level script could use "kernel.syscall.fork" as a
symbolic reference.



[...] The schemes of implementing the probe on function probe exit have
involved having an implicit probe on the function entry to set things
up for the function exit. Either the multiple probe actions (explicit and
implicit) will need to be combined into one probe or kprobes will need to
allow multiple probes at a particular probe point.


Right, or perhaps the kprobes layer can hide the implementation details
of exit-time probes from the kprobes API, so that coincidental entry-time
probes don't need to be aware.  kprobes would take care of exit-probe
setup before launching into any user-given entry probe.

It would be possible to implement multiple kprobes for a point. This would allow simple-minded implementation of the exit probe, but it would have more overhead with two probes rather than one at a point (still only one trap per point).


Alternatively, the probe compiler could group merge the probes together. The probe compiler would need to have a global view of the instrumentation and could just emit the C code on a probe by probe basis.

-Will


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