This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Reviewing Tapset code
- From: William Cohen <wcohen at redhat dot com>
- To: SystemTAP <systemtap at sources dot redhat dot com>
- Date: Wed, 30 May 2007 11:20:32 -0400
- Subject: Reviewing Tapset code
Currently we don't have a good idea of the amount of code in the tapset library
is exercised by the testsuite. There is a bugzilla entry for work related to
this, 4529, which I have on my action item list.
I did some simple command line to get an idea of the size of the tapsets and the
amount of guru mode used.
There is about 25K lines (including comments and blank lines) in the 57 .stp
files with about 356 probes/functions using guru mode in 49 files.
A significant amount of code is in the LKET directory, 7.2K lines. All of the
LKET files have guru mode code in them, because _lket_trace is implemented as a
C define, so each function that is tracing needs to use _lket_trace and is in
guru mode. The lket_trace define uses varargs, and need to be check to make sure
that the arguments agree.
LKET/lket_trace:update_record() changes internal systemtap data structure,
Stp_pbuf. It really shouldn't be doing that.
In LKET hookid_defs.stp a lot of the verbosity could be remove by using global
initializers rather than declaring the variable in one place and then
initializing it in hookid_init(). Something like the following:
global HOOKID_NFSD_PROBE_CREATE_RETURN = 38
-Will