Under linux-2.0.35, <linux/ip_fw.h> defines struct ip_fw to have
members fw_pcnt and fw_bcnt as unsigned long. This sounds reasonable.
Under glibc-2.0.7, <netinet/ip_fw.h> defines that same struct ip_fw to have
members fw_pcnt and fw_bcnt as u_int32_t. At first glance that might sound
reasonable too. But it is not. To my Alpha, long and u_int32_t are two
different animals. ipfwadm (stock from RedHat-5.1/AXP) is unusable for
this reason. To fix, I had to redefine those pesky u_int32_t's as longs
and recompile ipfwadm. netstat appears to have this same problem. Surely
there is something amiss here. What exactly is the fix?
1.) Fix glibc so it doesn't use specified-sized variables where they can
hurt (for instance, u_int8_t is always safe, and u_int32_t is always safe
for something like an ipv4 addr, but not necessarily other things).
2.) Fix ipfwadm et al to not include <netinet/ip_fw.h> and preference
<linux/ip_fw.h> instead. But wouldn't this contradict one of the purposes
of glibc, however?
In any case, what is the point of glibc hard-coding byte and packet
counters to a measly 32 bits anyway? ;) It seems like it would better
serve to let most variables match the natural size for the underlying
architecture. Thoughts?
Finally, I am wondering what ramifications (if any) the new 2.1.x ipchains
will have with glibc and userland net tools.
thanks,
-bp
-- B. James Phillippe <bryan@terran.org> Linux Software Engineer, WGT Inc. http://earth.terran.org/~bryan
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html