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