(tcpmib|ipmib|linuxmib)_filter_key function use and operation in tcpmib.stp, linuxmib.stp, and ipmib.stp

(tcpmib|ipmib|linuxmib)_filter_key function use and operation in tcpmib.stp, linuxmib.stp, and ipmib.stp

[William Cohen]

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