Reduction of guru use in systemtap war stories

[William Cohen <wcohen at redhat dot com>]

I am looking through the war stories and figuring out how to clean
things up.  Out of the 28 war stories 12 require guru mode.  Seems
like there should be fewer examples requiring the use of guru
mode. Three of the examples (WSimmortal, WSprintkBootParams, and
WSautoNice) are writing writing to kernel variables, which will always
require guru mode. WSPanicOnOom call kernel panic function. For the
remaining war stories using guru mode there a some idoms that are not
easily available from the tapsets.

WSthreadCPUshare uses guru mode to determine the instruction pointer
value for the sample and then determine whether this value is in
kernel or user-space. For some 32-bit kernels this approach is not
correct. A better approach would be make the kernel function
user_mode() available in the tapsets. This eliminate the need for guru
mode WSthreadCPUshare.

Some of the other war stories (WSPfiles, WSPsig, and WSPlimit) the
idiom to map a pid to a task struct point comes up and would be a
candidate to add to the tapsets. It looks like some of the other guru
functions in those scripts are already available and can be recast as
task.stp tapset functions. I will see if can reduce the scope of guru
functions used in these war stories examples.

Several of the war stories (such as WSPfiles) include header files and
make use of defines to extract bits/flags out of values. Seems like
there should be a cleaner way to make those bit values available to
scripts.

-Will