Re: AIX BPF driver load

[Guy Harris <gharris () sonic net>]

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