From owner-freebsd-current Mon Jan 12 18:48:59 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA16390 for current-outgoing; Mon, 12 Jan 1998 18:48:59 -0800 (PST) (envelope-from owner-freebsd-current) Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA16360 for ; Mon, 12 Jan 1998 18:48:38 -0800 (PST) (envelope-from tlambert@usr01.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id TAA23155; Mon, 12 Jan 1998 19:48:33 -0700 (MST) Received: from usr01.primenet.com(206.165.6.201) via SMTP by smtp01.primenet.com, id smtpd023126; Mon Jan 12 19:48:25 1998 Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id TAA17582; Mon, 12 Jan 1998 19:48:23 -0700 (MST) From: Terry Lambert Message-Id: <199801130248.TAA17582@usr01.primenet.com> Subject: Re: Firewall in kernel? - Found it! To: mike@smith.net.au (Mike Smith) Date: Tue, 13 Jan 1998 02:48:23 +0000 (GMT) Cc: current@freebsd.org In-Reply-To: <199801120141.MAA00554@word.smith.net.au> from "Mike Smith" at Jan 12, 98 12:11:34 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Your proposal's not new either. Your offer to help run it is, but > realistically do you feel that you have the time and stamina to do > nothing but vet endless permutations of changes to the system? Don't vet. Just guarantee compiles. I. Add three new commands: cvs lock read Assert a read lock on the CVS tree cvs lock write Assert a write lock on the CVS tree cvs unlock Deassert a read or write lock on the CVS tree. If deasserting a write lock, you are prompted for a comment describing the one or more files written while the lock was asserted. II. Change the source tree to be world readable, but only group writeable; the cvs lock write adds the group to your current process and starts a subshell. You *must* write lock. You *should* provide a comment when you unlock. Unlocking a write lock creates a change tag associated with the lock. We can now see who broke the tree, and we can back out *only* the breakage. After each cvs command, the lock status is printed to remind people to unlock. The following is the lock truth-table: Current state is None R W W+PR R+PW W+PW Request R G G B B B(1) B(1) Request W G B B B(1) B(1) B Key G Lock is granted B Lock is blocked Notes 1 Write requests have higher priority than read requests. All blocked requests are queued and remain queued unless aborted. Write requests are served preferentially. III. Allow reads with override (attempt to update/checkout without a read lock will say "no read lock -- continue?". You may override this with -q or -Q, or by explicity typing "y"/"Y". Default is "n"/"N". This lets people who think write-locking will slow them down from reading choose to take the risk. IV. Locks over a certain age can be "forced". Age is determined by "time of last CVS operation". Force is allowed to members of specified group ("wheel"/"committers"/"core"/whatever). Alternately, other methods of "stale lock" detection can be used (idle tim, whether the user with the lock is logged in or not, etc. -- this is a policy decision for core). V. All CVS tree mirrors must obtain a read lock to mirror; this is implemented in the CVSup server process.. CVSsup is no longer permitted on the main repository machine, except by mirrors, to reduce the amount of time a read lock may be held on the main repository. This *guarantees* a tree snapshot will be internally consistent across a change. It does *not* guarantee that a tree will not be corrupted by a writer (that guarantee requires policy enforcement. VI. A policy is established whereby all commits must use the following procedure:" 1) cvs lock write 2) cvs update copy of tree 3) resolve conflicts, if any 4) apply patches, if any 5) verify compilation. If dependencies worked, this would be a "make" succeeding... i) Subtask: fix the damn make dependencies 6) If compilation fails, go to (3) 7) cvs unlock 8) Enter comment describing overall changes This will pretty much answer all complaints, except those of people too lazy to type "cvs lock write"/"cvs unlock", and/or too lazy to describe the changes they made, in vague terms. Do you really want those people committing code to your tree anyway? If the controls are in place, and policy is followed, the tree is *guaranteed* to always build. > We already *have* a lazy vetting system, with many hundreds if not > thousands of participants, and a reasonably adequate feedback > mechanism. Trying to improve substantially on this would require a lot > of work. 8) To those who say this will be cumbersome, I say "What drugs are you on!?! yYou are always telling me how this level of synchronization is unnecessary because there are only one or two people in at a time". To those who say "this solves a non-problem", I say "you are currently reading about the problem; see the list archives for other occurrances". This is *trivial* to implement. Worst case, you can write a front end program, call it "cvs" and run "realcvs" after validating the command arguments for read/write. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.