Re: BPF_MEMWORDS

[Guy Harris <guy () alum mit edu>]

On Wednesday, August 6, 2003, at 12:16 AM, George Bakos wrote:

> As DRAM is rather more abundant than in 1998, perhaps we can allocate a
> bit more towards the scratch registers. In particular, this would open 
> up
> the limits on bpf expression length, reducing the need for multiple 
> filter
> files in cases that would otherwise throw a "too many registers needed"
> error.
>
> Any political, religious, or perhaps, cs reasons why the following is
> unreasonable?

It sounds reasonable, although note that there's more than one BPF 
interpreter libpcap has to deal with - there's its own BPF interpreter, 
used when reading savefiles and when capturing on platforms where 
there's no native BPF interpreter, but there're also the BPF 
interpreters in various BSDs (16 in current FreeBSD, NetBSD, OpenBSD, 
and Mac OS X - it might be bigger in BSD/OS), in AIX (probably 16, as 
their BPF probably hasn't been updated in a while), and WinPcap.

This might call for a "pcap_memwords_count(pcap_t *)" API, perhaps 
combined with an ioctl to get BPF_MEMWORDS from the kernel's BPF (if 
the ioctl was absent from the system where libpcap was built, or from 
the system where libpcap is running, it should probably return 16).  
Any BPF interpreter that raises the limit should also implement the 
ioctl.

Other information that might be useful to supply would be an indication 
of whether it had any of the new BSD/OS instructions such as the IPv6 
header parser (we might want to use it instead of generating backward 
branches for protochain - if the kernel's BPF interpreter has it, we 
can use it, and, if it doesn't, we'd do the filtering in userland; no 
kernel BPF interpreter I know of supports backward branches, so we 
currently do the filtering in userland for protochain as our userland 
interpreter does support them).

-
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