From owner-freebsd-current Tue May 6 14:54:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA07668 for current-outgoing; Tue, 6 May 1997 14:54:10 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id OAA07663 for ; Tue, 6 May 1997 14:54:07 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA19450; Tue, 6 May 1997 14:51:01 -0700 From: Terry Lambert Message-Id: <199705062151.OAA19450@phaeton.artisoft.com> Subject: Re: Bug: is it the kernel or the man page? To: joerg_wunsch@uriah.heep.sax.de Date: Tue, 6 May 1997 14:51:01 -0700 (MST) Cc: current@FreeBSD.ORG In-Reply-To: <19970506204702.SL03519@uriah.heep.sax.de> from "J Wunsch" at May 6, 97 08:47:02 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Well, I was actually thinking along the lines of: > > > > fcntl( fd, F_SETLK | F_NONPOSIX, &flock); > > This doesn't look too gross. > > > I also want to support mandatory file locking: if the file is SGID > > *and* the group execute bit is not set, the file would not be allowed > > to be mmap'ed, and a flag would be set duirng the open to indicate > > mandory locking was in effect. > > I think that's quite a large change to the code base. I've read > enough argumentations that mandatory file locking is basically > useless... so i won't go into any discussion here. I may or may not agree with this. The point is ABI compatability with Solaris requires it whether you or I like it or not. It has value for PC file servers, on top of this, which must "shadow" their mandatory locks, either by O_EXCL (mandatory file locking, which BSD currently supports), and which are not otherwise protected from or interoperable with UNIX programs running against the same file at the same time. Makes it hard to do "file sharing client/server" apps., where the IPC is via the contents of a file on a mapped resource. It's actually not that large a change. The largest changes are in seperating the "assert" and "commit" phases for locks so that NFS can back out a lock that it tried to assert over the wire, but which failed, without damaging the local copy of the lock lists. Basically, this is simply delaying the lock list coelesce until after the remote lock has succeeded so that the individual lock can be locally backed out if the remote assert has failed. The changes for mandatory locking are actually trivial, and end up being mostly and extra 'and' and 'bne' in the read, write, and mmap paths (the "not mandatory" cases). > > > There are other people capable of fixing man pages as well. I think > > > the only change by now should be to add a hint to fcntl-style locking > > > to close(2). > > > > This is exactly the man page fix I want. > > So i've filed a PR on your behalf for this. :) Thanks! Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.