On Wed, Nov 08, 2000 at 12:28:25AM +1100, Darren Reed wrote:

 > What about if a pfil hook is called from elsewhere (say ICMP), gets
 > the mbuf passed and tries to run a BPF filter over the IP + ICMP
 > header ?  Or should that filter never look at the IP header ?

Rules for IP won't be on ICMP's "filter hook" (I said I had other
changes that I just hadn't posted yet :-)

...in any case, it was never my plan to add a filter hook for ICMP.

 > You haven't mentioned why you want them in network byte order, here,
 > but if you're using BPF for the filtering, I have to wonder whether
 > this is beneficial.  The alternative of chaning BPF isn't attractive
 > either.

Uh ... the reason I want them in network byte order is precisely because
I'm using BPF.  Rule compilers for BPF (such as the one in libpcap, which
is what I'm using to compile my classification rules) assume they're
getting a raw packet off the wire.

Also, I want to add filtering points in the Ethernet code, and I have
filtering points in some forthcoming bridging code ... note that these
are getting raw Ethernet frames, and thus the fields are in network
byte order.

Yes, using BPF is beneficial -- the code is very compact, reasonably
fast, fairly easy to extend (itojun and I will be making some improvements
to BPF to support IPv6 more efficiently, and I have some extensions to
BPF that I'm considering that would put some of my classification engine's
functionality into the BPF virtual machine itself).

BPF also has a very simple instruction set, which, especially on RISC
CPUs, is easy to do run-time code synthesis with.  This is something
I plan on adding to BPF for at least a few architectures.  The benefit
to doing synthesis in the kernel is that you can do it after running
bpf_validate() -- it's hard to validate object code loaded into the
kernel.

-- 
        -- Jason R. Thorpe <thorpej@zembu.com>