On Jul 4, 2025, at 2:36 PM, Michael Richardson <m...@sandelman.ca> 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:
cBPF for live Linux kernel captures without VLAN tag support;
cBPF for live Linux kernel captures with VLAN tag support;
cBPF for Npcap NPF kernel captures with VLAN tag support;
cBPF for everything else.
In the future, we might also have eBPF for some or all of those as well.
In the longer term, the compilation process should probably be split into:
a phase that compiles a filter into a target-independent *and*
link-layer-independent *and* snapshot-length-independent intermediate
representation, optionally doing whatever optimization can be done with that;
a phase that compiles that intermediate representation into
optionally-optimized code for a particular link layer, snapshot length, and
target.
That would be used, for example, when reading a pcapng file with a
full-pcapng-support API; the filter for the handle for that file would be set
to the generated intermediate representation from the first phase and, for each
new link-layer/snapshot length pair in the file, would generate the appropriate
code for the filter, caching the results.
_______________________________________________
tcpdump-workers mailing list -- tcpdump-workers@lists.tcpdump.org
To unsubscribe send an email to tcpdump-workers-le...@lists.tcpdump.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
