On Thu, Apr 05, 2007 at 07:40:58PM -0400, J. Bruce Fields wrote: > From: Marc Eshel <[EMAIL PROTECTED]> - unquoted > > Acquiring a lock on a cluster filesystem may require communication with remote > hosts, and to avoid blocking lockd or nfsd threads during such communication, > we allow the results to be returned asynchronously. > > When a ->lock() call needs to block, the file system will return -EINPROGRESS, > and then later return the results with a call to the routine in the fl_notify > field of the lock_manager_operations struct. > > Note that this is different from the ->lock() call discovering that there is a > conflict which would cause the caller to block; this is still handled in the > same way as before. In fact, we don't currently handle "blocking" locks at > all; those are less urgent, because the filesystem can always just return an > immediate -EAGAIN without denying the lock. > > So this asynchronous interface is only used in the case of a non-blocking > lock, > where we must know whether to allow or deny the lock now. > > We're using fl_notify to asynchronously return the result of a lock > request. So we want fl_notify to be able to return a status and, if > appropriate, a conflicting lock. > > This only current caller of fl_notify is in the blocked case, in which case > we don't use these extra arguments. > > We also allow fl_notify to return an error. (Also ignored for now.)
I don't really like the overload of fl_notify. What the reason not to use a separate callback? - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
