Date: Sat, 10 Jan 1998 20:42:48 -0600 (CST) From: Alex Nash <nash@mcs.net> To: shimon@simon-shapiro.org Cc: nash@mcs.net, kong@kkk.ml.org, Studded@dal.net, current@freebsd.org, thyerm@camtech.net.au Subject: Re: Firewall in kernel? - Found it! Message-ID: <199801110242.UAA10815@nash.pr.mcs.net> In-Reply-To: <XFMail.980110142454.shimon@simon-shapiro.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199801110242.UAA10815>