From owner-freebsd-current Sat Jan 10 19:53:23 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA06355 for current-outgoing; Sat, 10 Jan 1998 19:53:23 -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 TAA06266 for ; Sat, 10 Jan 1998 19:52:42 -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 VAA11086; Sat, 10 Jan 1998 21:41:07 -0600 (CST) (envelope-from alex) Message-Id: <199801110341.VAA11086@nash.pr.mcs.net> Date: Sat, 10 Jan 1998 21:41:06 -0600 (CST) From: Alex Nash Subject: Re: Firewall in kernel? - Found it! To: shimon@simon-shapiro.org cc: current@freebsd.org 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: > 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. One of these time losses is incurred with every commit, the other is not. Therefore the net worth of this methodology really depends on how often the latter occurrs (I'm not convinced that the tree is broken often enough to make this a net gain). > 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. How do you define who all the afflicted parties are? Locking /etc/rc.conf seems an extreme price to pay for working on the firewall code. And what about libalias? Until two days ago there were no ties between it and ipfw, so again the problem would have gone unchecked. Now you could say that the committer of the libalias code has to lock ipfw beforehand, but locking a subsystem because you plan to use its interface seems extreme. Alex