From owner-freebsd-hackers Tue Jul 1 16:07:23 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA28801 for hackers-outgoing; Tue, 1 Jul 1997 16:07:23 -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 QAA28795 for ; Tue, 1 Jul 1997 16:07:18 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id QAA05274; Tue, 1 Jul 1997 16:05:27 -0700 From: Terry Lambert Message-Id: <199707012305.QAA05274@phaeton.artisoft.com> Subject: Re: POSIX locking ( was NFS locking) To: julian@whistle.com (Julian Elischer) Date: Tue, 1 Jul 1997 16:05:26 -0700 (MST) Cc: terry@lambert.org, lederer@bonn-online.com, freebsd-hackers@FreeBSD.ORG In-Reply-To: <33B985FA.3F54BC7E@whistle.com> from "Julian Elischer" at Jul 1, 97 03:34:34 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-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk [ ... POSIX brain damage ... ] > I suggest that we have a per-process flag that allows the locks to be > done per-fd. > it would break posix, but if you had posix by default, and this > only if you set it, then it would still be posix complient. I was thinking of an fcntl-based semantic overide, set on a per fd basis. Something like: int i = 1; fcntl( fd, F_NONPOSIX, &i); or even fcntl( fd, F_NONPOSIXCLOSE, &i); if we wanted to be anal about the meaning of the flag. This would really be the best way to handle it, without really breaking POSIX (default it to on). That way the per process semantics are still POSIX. I could easily envision a process that was mixed POSIX and non-POSIX I/O. A per fd overide makes a lot more sense than a per process overrride in that case. Plus the file struct has to be there anyway for you to close it or anything else, for that matter. > such things as samba and nfslockd could flip the bit and get > useful semantics. Yes. I thought that proxy locking would be useful for service as well. I left enough spare space in the compatability struct that I defined for communicating the remote system ID and process ID such that versioning could be done without having to change the struct in an incompatible way. The trick on versioning it for the remote ops is that the local ops have implied field values (ie: you can't get the lock data for a remote lock locally). This leaves the call binarily backward comaptible, which was the main design goal. > Anyone think this is a TERRIBLE idea? Nope. 8-). Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.