Re: architecture paper draft

["Frank Ch. Eigler" <fche at redhat dot com>]

Hi -


wcohen wrote:

> Here is a strawman for specifying locations for instrumentation.

Thanks, it's a good start!

> [...] Related types of instrumentation techniques and operations
> are grouped together into instrumentation schemes in SystemTAP.

(For what it's worth, and it's not much, I disprefer the CaMeLcApS.)


> [...]
> The syntax of the probe specifier is fairly simple. There may be
> additional restrictions due to the details of the instrumentation
> scheme [...]

Good.

> [...]
> /* FIXME details on how arguments and return value accessed */

Indeed: the whole data access namespace is key to this effort.
Function parameters are just one source of information.  The
script language also needs to allow reference to exported
globals, and with debugging-data support, statics, unexported
variables, locals within inner scopes of a function.  (That
last bit of course requires a probe placement syntax to specify
functions' internal locations.)

 
> [...]
> Use of Kernel Data structures for Probe points
> 
> Due to the use of modules and devices drivers there are a number of
> common data structures that are used to pass lists of methods to the
> kernel. [...]
> Below is a proposed probe specifier for the virtual file system. 
> 
> probe vfs.filesystem(name_list).(file|inode|sb).operation(name_list)(/* implicit entry */| .entry | .return

The reason that these baby-OO structures are used in the kernel is
because the operations chosen are dependent on the specific object
(type of filehandle, type of filesystem, type of network interface,
protocol, memory manager) associated with a given base object.  So
we need to make clear whether thes probes are supposed to be related
to (say) a given filehandle or socket or process, or broadly defined
to include entry points into a given module irrespective of them.

What would help clarify what you mean is a snipped ot pseudocode that
shows what systemtap would expand such probe specifications to: how
it would calculate those breakpoint addresses during initialization.

Another interesting angle is to think about how to generalize this
mechanism to provide some run-time extensibility for systemtap, so
that such a probe-specification namespace might be populated at
startup time from a library of scripts.  This would be in some ways
preferable to having to hardcode in systemtap the interpretation
of these specifications.  This would definitely require pseudocode
fragments to illustrate.


- FChE

Attachment: pgp00000.pgp
Description: PGP signature