At 12:52 PM +0930 8/28/99, Greg Lehey wrote:
FreeBSD is one of the few operating systems which doesn't have
kernel-level locking. If we want to emulate other systems correctly,
we *must* have advisory locking. This includes SCO UNIX, System V.4
and Linux. I suspect it also includes Microsoft.
All this doesn't leave too much room for arguments about whether
locking works or not: it works on all platforms except FreeBSD, and
that's only because FreeBSD doesn't implement locking.
I agree (for what it's worth)
As a result, I argue that we should implement locking. The questions
are: how? I'd suggest three ... [the third being:]
- Via separate calls to fcntl. fcntl currently has the following
command values:
#define F_DUPFD 0 /* duplicate file descriptor */
#define F_GETFD 1 /* get file descriptor flags */
#define F_SETFD 2 /* set file descriptor flags */
#define F_GETFL 3 /* get file status flags */
#define F_SETFL 4 /* set file status flags */
#define F_GETOWN 5 /* get SIGIO/SIGURG proc/pgrp */
#define F_SETOWN 6 /* set SIGIO/SIGURG proc/pgrp */
#define F_GETLK 7 /* get record locking information */
#define F_SETLK 8 /* set record locking information */
#define F_SETLKW 9 /* F_SETLK; wait if blocked */
We could add a F_SETMANDLOCK or some such.
Any thoughts?
On this last option, I assume that means a program could open
some file, set this option, and then other programs would behave
as if the mandatory-locking flag was on for that file. However,
that behavior would only last as long as the first program, the
one which set the option, still had the file-descriptor open?
Presumably this new fcntl value would only be honored for
programs executing as the owner of the file? (or some other
limited group, to limit denial-of-service attacks)
---
Garance Alistair Drosehn = g...@eclipse.acs.rpi.edu
Senior Systems Programmer or dro...@rpi.edu
Rensselaer Polytechnic Institute
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
