Date: Sat, 10 Jan 1998 19:25:28 -0800 (PST) From: Simon Shapiro <shimon@simon-shapiro.org> To: Alex Nash <nash@mcs.net> Cc: thyerm@camtech.net.au, current@freebsd.org, Studded@dal.net, kong@kkk.ml.org Subject: Re: Firewall in kernel? - Found it! Message-ID: <XFMail.980110192528.shimon@simon-shapiro.org> In-Reply-To: <199801110242.UAA10815@nash.pr.mcs.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 11-Jan-98 Alex Nash wrote: > 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). Again, I am not talking about this particular incident. Every breach of procedure and every compromise always have convincing reasons behind them. > 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. Proves my point. >> 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... There are at least seven different ways to skin a cat. Complete and rigid serializing is only one. There are others. You also have to consider overall cost. Consider this: While you may have saved an hour or six by not serializing your process, the totall loss of time for the project was the accumulated failure time and debug time and fix time, and discussion time for the entire project. As life is full of compromises, we may want to consider one more here. What is the balance between the breakage in compilation and free hacking to one's content. My view is that, today, the FreeBSD project is unbalanced in this regard. Assume we had a way to reliably ``lock'' the IP Firewall code and issue an advisory lock to all afflicted parties (this technology is available; I have demonstrated such a system on the original Tahoe). In this model, the first to grab a ``lock'' on IP firewalls, will becone the focal point (the ``submitter'') for all code relating to IP firewalls. Of all Free O/S projects, it looks to me that FreeBSD is the closest to be able to implement this model; we seem to have the best source tree management already in place. It is also amoung the largest such projects, with the largest number of authoritative contributors. ---------- Sincerely Yours, Simon Shapiro Shimon@Simon-Shapiro.ORG Voice: 503.799.2313
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.980110192528.shimon>