tcpdump mailing list archives
Re: AIX BPF driver load
From: Guy Harris <gharris () sonic net>
Date: Thu, 6 Feb 2003 22:29:39 -0800
On Fri, Feb 07, 2003 at 05:10:50PM +1100, Shaun wrote:
So I'm not sure if this will actually have any effect (i.e if the AIX implementation will "just work" with the 64 bit sized version) or if I should force use of the 32 bit version with a #define.
Hmm. I suspect that, on a 64-bit Power* machine, the kernel code for BPF is 64-bit code. One possibility is that it checks whether the user-mode application that opened the BPF device was a 32-bit application or a 64-bit application, and supplies a "bpf_hdr32" if it's 32-bit (for binary compatibility) and a "bpf_hdr" if it's 64-bit. The other possibility is that it always supplies a "bpf_hdr32" but they kept the "bpf_hdr" structure around for some reason. My *guess* is that it's the first of those. However, I don't know whether libraries are also 32-bit or 64-bit; I suspect so. If so, a 64-bit application might have to link with a 64-bit libpcap, in which case if 32-bit code is built by default (as I suspect is the case) the 32-bit library would work just fine, but the 64-bit library would, if a "bpf_hdr" is supplied, copy that, field by field, to a "pcap_pkthdr" and pass a pointer to that structure to the callback. Too bad BPF didn't use "bpf_u_int32" *AND* something like "pcap-int.h"s "pcap_timeval" since the beginning, but there are a number of things BPF and libpcap "should have done" since the beginning - but it wasn't always obvious *at the time* that they should've done it. (E.g.: having values for the data link type separate from DLT_ values, so that different OSes with BPF could've used different DLT_ values without the problems for which we now attempt to compensate; having the "promisc" argument to "pcap_open_live()" being a "flags" argument, with "read vs. write. vs. read-write" flags as well as a "promiscuous mode" flag, so that various new features (such as allowing opening for capturing *and* sending without requiring that all users be able to open for both) could be added without having to add a new routine to open live captures; libpcap's savefile-reading code rejecting major version numbers not equal to PCAP_VERSION_MAJOR, not just major version numbers less than PCAP_VERSION_MAJOR, so that an incompatible format change could be introduced without changing the magic number; having a parse-tree format generated by a filter-expression parser, and have *that* be the argument to "pcap_setfilter()", so that it could attempt to do filtering in the kernel on systems that support kernel filtering but don't support BPF, and punt to user-mode filtering if the filter can't be handled by the kernel; having "pcap_stats()" return a variable-length type/value table rather than a fixed set of statistics, so that new statistics can be added, and the ability to return *fewer* statistics than are in a "struct pcap_stat" (if not all those statistics can be done on a platform), without an API change. - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:tcpdump-workers-request () tcpdump org?body=unsubscribe
Current thread:
- AIX BPF driver load Shaun (Feb 05)
- Re: AIX BPF driver load Guy Harris (Feb 05)
- Re: AIX BPF driver load Guy Harris (Feb 05)
- <Possible follow-ups>
- Re: AIX BPF driver load Guy Harris (Feb 06)
- Re: AIX BPF driver load Shaun (Feb 06)
- Re: AIX BPF driver load Guy Harris (Feb 06)
- Re: AIX BPF driver load Shaun (Feb 06)
- Re: AIX BPF driver load Guy Harris (Feb 06)
- Re: AIX BPF driver load Guy Harris (Feb 07)
- Re: AIX BPF driver load Shaun (Feb 09)
- Re: AIX BPF driver load Guy Harris (Feb 10)
- Re: AIX BPF driver load Guy Harris (Feb 10)
- Re: AIX BPF driver load Guy Harris (Feb 10)
- Re: AIX BPF driver load Shaun (Feb 10)
- Re: AIX BPF driver load Guy Harris (Feb 10)
- Re: AIX BPF driver load Shaun (Feb 06)
- Re: AIX BPF driver load Guy Harris (Feb 05)