> 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 ([EMAIL PROTECTED]) Realtime development, Machine control,
HD Associates, Inc. Safety critical systems, Agency approval
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
