> As a result, I argue that we should implement locking. The questions > are: how? I'd suggest three methods which can be individually enabled > via sysctls: > > - System V style. We need this for compatibility with System V. The > choice of mandatory or advisory locking depends on the file > permissions. > > - Only mandatory locking. fcntl works as before, but locks are > always mandatory, not advisory. I'm sure that this won't be > popular, at least initially, but if you don't like it, you don't > have to use it.y > > - 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?
(I'm following up only on -hackers because I personally hate discussions in -commit.) Yes - 1. Isn't vinum a device? Isn't this file-level locking irrelevant? Shouldn't all locking for maintenance be done at the device level? 2. I'll bet there are some standards, at least in development. Have you done a few searches? I have other opinions, some that I hold strongly, but since they have to do with lack of definition of boundary conditions then I won't bring them up until (2.) is answered. Peter -- Peter Dufault (dufa...@hda.com) Realtime development, Machine control, HD Associates, Inc. Safety critical systems, Agency approval To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
