From owner-freebsd-current Sat Jan 10 19:16:48 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA00585 for current-outgoing; Sat, 10 Jan 1998 19:16:48 -0800 (PST) (envelope-from owner-freebsd-current) Received: from nash.pr.mcs.net (nash.pr.mcs.net [204.95.47.72]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA00519 for ; Sat, 10 Jan 1998 19:16:32 -0800 (PST) (envelope-from alex@nash.pr.mcs.net) Received: (from alex@localhost) by nash.pr.mcs.net (8.8.8/8.8.7) id UAA10815; Sat, 10 Jan 1998 20:42:49 -0600 (CST) (envelope-from alex) Message-Id: <199801110242.UAA10815@nash.pr.mcs.net> Date: Sat, 10 Jan 1998 20:42:48 -0600 (CST) From: Alex Nash Subject: Re: Firewall in kernel? - Found it! To: shimon@simon-shapiro.org cc: nash@mcs.net, kong@kkk.ml.org, Studded@dal.net, current@freebsd.org, thyerm@camtech.net.au In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On 10 Jan, Simon Shapiro wrote: > a. All checked-in patches must be make in this manner: > > 1. Update your source tree via agreed, singular method (reduces race > conditions) to the moment. > > I do that by running cvsup late at night, several times, until I > get ZERO changes. > > 2. Apply your patches to that fresh, new tree. > > 3. run ``make buildworld''. no need to re-install your machine - All > we are after here is a clean compile, not correct behavior. > > 4. cd /usr/src (or wherever your clean, just correctly built tree is) > > 5. cvs diff -c -N > ../my_patch > > 6. cvs commit... While these steps are highly recommendable (I try to check commits against up-to-the-minute sources in a similar way), they can't prevent problems such as the one involved in this thread (i.e. the exit codes for ipfw causing breakage for the non-firewall kernels). Ironically, I just received another related example: Mikael Karpberg just contacted me regarding the 'Firewall in kernel' thread. He pointed out that 'options IPFIREWALL' in conjunction with DEFAULT_TO_ACCEPT causes rc.network to complain that IP services are disbled even when they're not (DEFAULT_TO_ACCEPT = wide open firewall). A quick check of the CVS logs reveals (note the dates): ip_fw.c revision 1.63 date: 1997/09/10 03:07:14; author: peter; state: Exp; lines: +16 -8 Allow a compile-time override of the ipfw deny rule. [Comments about people who can't keep user/kernel in sync elided] rc.network revision 1.10 date: 1997/09/11 10:59:02; author: danny; state: Exp; lines: +32 -5 Reviewed by: msmith, alex Cosmetic changes to the loading of firewall rules and lkm. Yet another cross commit with unintended side effects. > Alternatively, consider serializing and checkpointing the process; > > All diffs are sent to a central authority. There they are applied to a > master tree, compiled and then released to the commit tree. This cycle can > be automated and run once or twice a day. I'll be happy to help in this > matter. There's at least one commercial VC product (Continuus) which enforces this with the concept of a build manager. I view the build manager as being a bottleneck and weak point of the development cycle, and I doubt that many FreeBSD committers would be willing to give up the current system to avoid the occassional spurious error message (even a build manager wouldn't have caught the two error messages above) or even the occassional build failure. But I could be wrong... Alex