On Thu, Dec 07, 2006 at 04:51:08PM +0000, Christoph Hellwig wrote:
> On Wed, Dec 06, 2006 at 12:34:10AM -0500, J. Bruce Fields wrote:
> > We'd like an asynchronous posix locking interface so that we can provide NFS
> > - We added a new ->lock() export operation, figuring this was a feature
> > that only lockd and nfsd care about for now, and that we'd rather not
> > muck about with common locking code. But the export operation is
> > pretty much identical to the file ->lock() operation; would it make
> > more sense to use that?
>
> This definitly needs to be merged back into the ->lock file operation
So the interesting question is whether we can merge the semantics in a
reasonable way. The export operation implemented by the current version
of these patches returns more or less immediately with success, -EAGAIN,
or -EINPROGRESS; in the latter case the filesystem later calls fl_notify
to communicate the results. The existing file lock operation normally
blocks until the lock is actually granted.
The one file lock operation could do both, and just switch between the
two cases depending on whether fl_notify is defined. Would the
semantics be clear enough?
I find the existing use of ->lock() a little odd as it is; stuff like this,
from fcntl_getlk():
if (filp->f_op && filp->f_op->lock) {
error = filp->f_op->lock(filp, F_GETLK, &file_lock);
if (file_lock.fl_ops && file_lock.fl_ops->fl_release_private)
file_lock.fl_ops->fl_release_private(&file_lock);
if (error < 0)
goto out;
else
fl = (file_lock.fl_type == F_UNLCK ? NULL : &file_lock);
} else {
fl = (posix_test_lock(filp, &file_lock, &cfl) ? &cfl : NULL);
}
--b.
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
