Date: Sat, 10 Jan 1998 21:41:06 -0600 (CST) From: Alex Nash <nash@mcs.net> To: shimon@simon-shapiro.org Cc: current@freebsd.org Subject: Re: Firewall in kernel? - Found it! Message-ID: <199801110341.VAA11086@nash.pr.mcs.net> In-Reply-To: <XFMail.980110192528.shimon@simon-shapiro.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199801110341.VAA11086>