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

[Robert Watson]

On Thu, 26 Feb 2004, Steve Kargl wrote:

> > Choice is good.  Three firewalls is maybe pushing the limit, but these
> > three are Very Important to our community.
> 
> ports/security/pf gave you choice.  This is a danger slope (ie., what
> about postfix, exim, bash, and ksh?). 

Well, there are some challenges that apply to maintaining kernel code
outside the source tree that don't apply so much to userspace code.
Especially on a -CURRENT branch, we change APIs pretty liberally, and the
locking work is very much still a work in progress.  While PFIL improves
code modularity from the perspective of avoiding lots of tearing up of the
input and output paths, it doesn't solve the problem of keeping code in
sync.  By bringing pf into the tree, we have a chance of snagging more
time from some folks who have clearly spent a lot of time with our network
stack, and could lend a hand :-).  The development/API argument doesn't
just affect the developers, FWIW, but also users: using third party kernel
modules over an extended period with a branch that moves like 5.x has
frequently introduces ABI issues, or you have to recompile the modules
every time you upgrade your kernel...

Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
robert at fledge.watson.org      Senior Research Scientist, McAfee Research