From owner-freebsd-current Sat Jan 10 20:08:51 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA07886 for current-outgoing; Sat, 10 Jan 1998 20:08:51 -0800 (PST) (envelope-from owner-freebsd-current) Received: from nomis.simon-shapiro.org ([206.190.143.100]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id UAA07880 for ; Sat, 10 Jan 1998 20:08:42 -0800 (PST) (envelope-from shimon@nomis.Simon-Shapiro.ORG) Received: (qmail 8329 invoked by uid 1000); 11 Jan 1998 04:07:39 -0000 Message-ID: X-Mailer: XFMail 1.3-alpha-010198 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199801110341.VAA11086@nash.pr.mcs.net> Date: Sat, 10 Jan 1998 20:07:39 -0800 (PST) Reply-To: shimon@simon-shapiro.org Organization: The Simon Shapiro Foundation From: Simon Shapiro To: Alex Nash Subject: Re: Firewall in kernel? - Found it! Cc: current@freebsd.org Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On 11-Jan-98 Alex Nash wrote: ... >> 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. You assume the existing data model for a source tree. This model is file-centric and assumes mutex locks only. My model is fragment-centric and dependencies are computed dynamically and automatically. In addition, locks are multi level, so that if you chage a header file, you force refresh (not lock-out) on .c files, etc. Also, note that the first authoritative lock on firewall code will force all other checkouts to checkin via the authoritative lock. That /etc/rc is now dependant on some .c file can either be deduced from source relations, or... has to be entered manually. Consider: foo >& /dev/null if [${?} != 0] ... as a dependancy. Now can we reliably abstract it mechanically? Probably. Do I (Simon) kow how to do it? Maybe. Is there a FreeBSD hacker around who know better and has time to write such a tool? I am sure the answer is yes. ---------- Sincerely Yours, Simon Shapiro Shimon@Simon-Shapiro.ORG Voice: 503.799.2313