Guy Harris wrote:
> In the longer term, the compilation process should probably be split
> into:
yes.
> a phase that compiles a filter into a target-independent *and*
> link-layer-independent *and* snapshot-length-independent intermediate
> representation, optionally doing
On Jul 4, 2025, at 2:36 PM, Michael Richardson wrote:
> In general, it seems to me like we ought to specify some kind of target BPF
> processor option. As you say, pcap mostly just adapts itself to the current
> kernel, and the dead version has no options.
Currently, the possible backends are:
Bill Fenner wrote:
> I have a little program that basically calls pcap_open_dead(),
> pcap_compile(), and then dumps the instructions like a C struct, so
> that we can include a bpf program in some other code that will use it
> later. (Like "tcpdump -dd", but with a little extra
On Jul 4, 2025, at 8:55 AM, Bill Fenner wrote:
> We may know that we will be using this code on a kernel that
> requires BPF_SPECIAL_VLAN_HANDLING, and so I'd like to be able to set that
> flag on a "dead" handle. Obviously, the current mechanism is to test this
> dynamically when the handle is
Hi all,
I have a little program that basically
calls pcap_open_dead(), pcap_compile(), and then dumps the instructions
like a C struct, so that we can include a bpf program in some other code
that will use it later. (Like "tcpdump -dd", but with a little extra
formatting.)
We may know that we wi
