architecture paper draft

[Frank Ch. Eigler]

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

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.


- FChE
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/systemtap/attachments/20050128/a1fc8859/attachment.sig>