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:



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

For code I prefer to use '_' to CaMeLcApS. Want to keep it as one word here, but make it visually easier to separate the word. It is a pain to type.


[...]
/* 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.)

Currently, I have just thought about the function boundary instrumentation. It would certainly be possible to have an instrumentation scheme that puts probes in the interior of functions that make local variables available.


One simple-minded approach for the function boundary instrumentation is use "$1", "$2", ... for the arguments for function entry and $0 for function return. I do not endorse that because the numbers are not particularly meaningful and someone is likely to need to look up the name for a specific argument. Symbolic names are more useful. However, just using the argument name of the original function could have name collisions with some global variable, so there probably still needs to be some means of distinguishing between argument and global scope variable.

File scope variables are commonly used in the drivers, so there will need to be some way of distinguishing between the variables of the same name in different files.

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

the ".filesystem(name_list)" to narrow down to which file system and ".(file|inode|sb)" to narrow down while part of the file system. These would be system wide instrumentation. The probe would need to have some check (predicate) to only fire on the interesting filehandle/socket/process. syntax sugar could specify this outside the probe body, but implementation-wise it seems to make sense to put that in the probe body. Do the check at the beginning of the probe body and exit early if the predicate isn't meet.


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.

Yes, I need to do some proof-of-concept implementation of these.


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.

I was expecting that some of this code would be in a runtime library because the addresses of the operations would not be known when the instrumentation script is compiled.



-Will



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