From owner-cvs-src@FreeBSD.ORG Thu Feb 26 12:09:27 2004 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 87EF316A4CE; Thu, 26 Feb 2004 12:09:27 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2F7E043D2F; Thu, 26 Feb 2004 12:09:27 -0800 (PST) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.10/8.12.10) with ESMTP id i1QK8VDL096562; Thu, 26 Feb 2004 15:08:31 -0500 (EST) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i1QK8VbX096559; Thu, 26 Feb 2004 15:08:31 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Thu, 26 Feb 2004 15:08:30 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Steve Kargl In-Reply-To: <20040226180354.GB73761@troutmask.apl.washington.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: "Jacques A. Vidrine" cc: cvs-src@FreeBSD.org cc: Max Laier cc: cvs-all@FreeBSD.org 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 X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2004 20:09:27 -0000 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