Re: BPF in hardware

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

On Nov 22, 2004, at 4:01 PM, Livio Ricciulli wrote:

> How far is the current implementation from this architecture?

None of it has been done - the only way to be further from that 
architecture would be not to have come up with that architecture.

Any change to support generating anything other than BPF code would 
involve an API change, as "pcap_compile()" is expected to return a BPF 
program - and there are probably callers of "pcap_compile()" that use 
the BPF program themselves, so there's no guarantee that having some 
special hack to reuse "struct bpf_program" to refer to something other 
than a BPF program would work.

A perhaps less intrusive short-term hack could be to add:

	a new API, similar to "pcap_compile()", that fills in a new structure 
that has a "filter type" indication;

        a new API for setting filters using that new structure.

That obviates the need to design the expression tree representation (as 
I'd like to be able to hand expression trees *not* constructed by 
libpcap's parser to the filter installer, that should be designed well 
enough to be usable and extensible as necessary), but does mean you'd 
have to do a lot of work on the *existing* code generator to make it 
emit stuff other than a BPF program, and it might be a bit more 
intrusive than having separate code generators (code generator routines 
are called from the parser).

-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.