Sometimes, a tapset needs provide data values from the kernel that
cannot be extracted using ordinary target variables ($var). This may be because the values are in complicated data structures, may
require lock awareness, or are defined by layers of macros. Systemtap
provides an ``escape hatch'' to go beyond what the language can safely
offer. In certain contexts, you may embed plain raw C in tapsets,
exchanging power for the safety guarantees listed in
section 3.6. End-user scripts may not include
embedded C code, unless systemtap is run with the -g (``guru''
mode) option. Tapset scripts get guru mode privileges automatically.
Embedded C can be the body of a script function. Instead enclosing
the function body statements in { and }, use %{
and %}. Any enclosed C code is literally transcribed into the
kernel module: it is up to you to make it safe and correct. In order
to take parameters and return a value, a pointer macro THIS is
available. Function parameters and a place for the return value are
available as fields of that pointer. The familiar data-gathering
functions pid(), execname(), and their neighbours are
all embedded C functions. Figure 10 contains
another example.
Since systemtap cannot examine the C code to infer these types, an
optional4 annotation
syntax is available to assist the type inference process. Simply
suffix parameter names and/or the function name with :string or
:long to designate the string or numeric type. In addition,
the script may include a %{ %} block at the outermost
level of the script, in order to transcribe declarative code like
#include <linux/foo.h>. These enable the embedded C functions
to refer to general kernel types.
There are a number of safety-related constraints that should be observed by developers of embedded C code.
trylock type call to attempt to take the lock. If that fails,
give up, do not block.