(tcpmib|ipmib|linuxmib)_filter_key function use and operation in tcpmib.stp, linuxmib.stp, and ipmib.stp
William Cohen
wcohen@redhat.com
Fri Sep 2 15:03:00 GMT 2011
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
More information about the Systemtap
mailing list