On Sun, Jun 27, 2010 at 02:06:31AM +0000, David Holland wrote: > On Sat, Jun 26, 2010 at 10:39:27AM +0200, Juergen Hannken-Illjes wrote: > > The vnode lock operations currently work on a rw lock located inside the > > vnode. I propose to move this lock into the file system node. > > > > This place is more logical as we lock a file system node and not a vnode. > > This becomes clear if we think of a file system where one file system node > > is attached to more than one vnode. Ptyfs allowing multiple mounts is such > > a candidate. > > I'm not convinced that sharing locks at the VFS level is a good idea > for such cases. While ptyfs specifically is pretty limited and > unlikely to get into trouble, something more complex easily could. I > don't think we ought to encourage this until we have a clear plan for > rebind mounts and the resulting namespace-handling issues. (Since > in a sense that's the general case of multiply-mounted ptyfs.) > > Since I'm pretty sure that a reasonable architecture for that will > lead to sharing vnodes between the multiple mountpoints, and > manifesting some kind of virtual name objects akin to Linux's dentries > to keep track of which mountpoint is which, I don't see that it's > necessary or desirable to specialize the locking... > > Do you have another use case in mind? > > (In the absence of some clear benefits I don't think it's a > particularly good idea to paste a dozen or two copies of genfs_lock > everywhere. But folding vcrackmgr() into genfs_lock and genfs_unlock > seems like a fine idea.)
Primary goal is to abstract vnode locking into the vnode operations only and therefore completely removing vlockmgr(). For now I can live with genfs_lock()/v_lock becoming the generic locking interface where v_lock becomes genfs_lock()-private. -- Juergen Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)