Date: Thu, 26 Feb 2004 15:08:30 -0500 (EST) From: Robert Watson <rwatson@FreeBSD.org> To: Steve Kargl <sgk@troutmask.apl.washington.edu> Cc: src-committers@FreeBSD.org Subject: Re: 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 Message-ID: <Pine.NEB.3.96L.1040226150526.79901Y-100000@fledge.watson.org> In-Reply-To: <20040226180354.GB73761@troutmask.apl.washington.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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@fledge.watson.org Senior Research Scientist, McAfee Research
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1040226150526.79901Y-100000>