cvs commit: src/sys/contrib/pf/net if_pflog.c if_pflog.h if_pfsync.c if_pfsync.h pf.c pf_ioctl.c pf_norm.c pf_osfp.c pf_table.c pfvar.h src/sys/contrib/pf/netinet in4_cksum.c

[Sam Leffler]

On Feb 26, 2004, at 7:11 AM, Luigi Rizzo wrote:

> On Thu, Feb 26, 2004 at 11:24:22AM +0100, Andre Oppermann wrote:
>> Luigi,
>>
>> do you have any patches ready or in the works to make ipfw2 use the
>> PFIL_HOOKS API?  That would simplify ip_input() and ip_output() a
>> *great* deal.
>
> no, i will try to look and see if i can implement something of use.
> But i don't think you'd save much more than the extra call to
> ip_fw_chk() -- things such as 'divert' and 'forward'
> greatly interact with the rest of the packet processing in ip_input()
> and ip_output(). If you look at the code, calling
> the firewall is a short block of code; the big offender is the
> processing after the firewall returns with a non-trivial action
> (especially 'forward' in ip_output()).

I made two attempts to eliminate all the ipfw-, dummmynet-, and 
bridge-specific code in the ip protocols but never got stuff to the 
point where I was willing to commit it.  My main motivation for doing 
this was to eliminate much of the incestuous behaviour so that you 
could reason about locking requirements but there were other benefits 
(e.g. I was also trying to make the ip code more "firewall agnostic").  
The changes involved replacing the well-known function pointers with 
PFIL_HOOKS, restructuring code and API's so non-ip code could move out 
of the ip protocol code, and the elimination of MT_TAG mbufs.  Max 
followed through getting the latter committed (thanks, great work!) and 
I hope to return to this when I've got free time.

	Sam