From mboxrd@z Thu Jan 1 00:00:00 1970 From: Trond Myklebust Subject: Re: [PATCH 2/5] POSIX Locking fixes. Take 2... Date: Tue, 29 Jun 2004 22:54:55 -0400 Sender: linux-fsdevel-owner@vger.kernel.org Message-ID: <1088564095.4573.178.camel@lade.trondhjem.org> References: <1088555285.4573.110.camel@lade.trondhjem.org> <20040630005455.GZ30334@parcelfarce.linux.theplanet.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: linux-fsdevel@vger.kernel.org, Andrew Morton Return-path: Received: from dh132.citi.umich.edu ([141.211.133.132]:44160 "EHLO lade.trondhjem.org") by vger.kernel.org with ESMTP id S265874AbUF3Cy4 convert rfc822-to-8bit (ORCPT ); Tue, 29 Jun 2004 22:54:56 -0400 To: Matthew Wilcox In-Reply-To: <20040630005455.GZ30334@parcelfarce.linux.theplanet.co.uk> List-Id: linux-fsdevel.vger.kernel.org P=E5 ty , 29/06/2004 klokka 20:54, skreiv Matthew Wilcox: > The thing that got me most confused when I was trying to rip fl_notif= y, > fl_insert and fl_remove out of the existing struct file_lock was that= one > of them is "owned" by the host fs, and two are owned by the exporting= fs. > Or was it the other way around... anyway, which is this new f_l_ops f= or, > and can fl_notify or fl_insert/fl_remove move into it? fl_ops is a hook to allow the VFS to call back the real lock manager whoever that may be. As far as NFS is concerned, the VFS is just a local scoreboard for keeping track of locks that we may need to clean up on file close() or reclaim in case of a server reboot (afaik this is pretty much all CIFS and GFS care about too - I've no idea abou= t the needs of Lustre and others). As far as lockd is concerned, the VFS representation of the loc= k has its usual local function, but lockd has its own private representation of the lockowner (it has a remote host + a remot= e pid). It does not care about the clean up on file close() stuff= =2E In addition, it needs special notification in the case where on= e lock is blocking on another lock. If this confuses you, then blame it on the fact that the blocking code uses the exact same struct file_lock to represent the blocker. If you prefer, we might split fl_ops + fl_notify/... into 2 structs: struct file_lock_operations { void (*fl_insert)(struct file_lock *); void (*fl_remove)(struct file_lock *); void (*fl_copy_lock)(struct file_lock *, struct file_lock *); void (*fl_release_private)(struct file_lock *); void (*fl_steal_locks)(struct file_lock *, fl_owner_t); }; struct lock_manager_operations { int (*fl_compare_owner)(struct file_lock *, struct file_lock *); void (*fl_notify)(struct file_lock *); }; That would in effect allow us to keep the lockd and the filesystem stuf= f separate: one in file_lock->fl_ops, the other in file_lock->fl_lmops. Cheers, Trond - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel= " in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html