This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
(tcpmib|ipmib|linuxmib)_filter_key function use and operation in tcpmib.stp, linuxmib.stp, and ipmib.stp
- From: William Cohen <wcohen at redhat dot com>
- To: SystemTAP <systemtap at sources dot redhat dot com>
- Date: Fri, 02 Sep 2011 11:03:08 -0400
- Subject: (tcpmib|ipmib|linuxmib)_filter_key function use and operation in tcpmib.stp, linuxmib.stp, and ipmib.stp
I am cleaning up the documentation for PR13101 ("Networking tapsets should have structured comment"), and the operation of the (tcpmib|ipmib|linuxmib)_filter_key functions looks a bit odd. The functions either return the op or 0. The return value is used as a key if it is non-zero. for example tcpmib-filter-default.stp has:
function tcpmib_filter_key:long (sk:long, op:long)
{
if (!sk) return 0
return op
}
In most cases op is 1, but here is an example use in tcpmib.stp that doesn't follow that:
tcpmib.CurrEstab = kernel.function("tcp_set_state").call ?
{
sk = $sk;
state = $state;
oldstate = tcpmib_get_state($sk);
TCP_ESTABLISHED = 1;
if ( oldstate == TCP_ESTABLISHED ) {
op = -1;
key = tcpmib_filter_key($sk,op);
if ( key ) CurrEstab[key] += op;
} else {
if ( state == TCP_ESTABLISHED ) {
op = 1;
key = tcpmib_filter_key($sk,op);
if ( key ) CurrEstab[key] += op;
}
}
}
The value of op is used both as the key for the associative array and the value to accumulate, which seems a bit odd. The values in linux /proc/net/snmp are scalars: http://lxr.linux.no/#linux+v3.0.4/net/ipv4/proc.c . Any insight to why this tcpmib.stp, and linuxmib.stp, and ipmib.stp use associative arrays in those cases?
-Will