Subject: Re: diffs for UVM/UBC improvements available
To: Bill Studenmund <>
From: Greywolf <>
List: tech-kern
Date: 05/29/2001 14:23:40
What do we gain by _not_ keeping the struct lock *?

On Tue, 29 May 2001, Bill Studenmund wrote:

# On Tue, 29 May 2001, Greywolf wrote:
# > Would I be putting it more simply to the lesser technical than yourselves
# > (such as, oh, me :-) to say that the layers still need that struct lock *
# > drilling down to the base layer so that locking on a node will actually
# > work, i.e. all layers ATOP the base point down to the lock at the base
# > level, while the struct lock * at the base is a real lock on the node,
# > hence any references on any other layer will actually perform the lock op
# > [if they're even permitted to do that]?
# > 
# > Or is that not even close?
# I think that's about it, except that "need" is a bit strong. With what we
# have now, there's a struct lock * in the vnode. Upper layers will look at
# the struct lock * in the lower node, and put it in their vnode (so a layer
# on a layer will work right).
# When VOP_LOCK() gets called on a layered node, if the struct lock * is
# non-NULL, the layer just goes ahead and calls the lock manager using that
# lock.
# If the struct lock * is NULL, the layer calls VOP_LOCK on the underlying
# vnode. The clustered file system Chuck spoke of would export a NULL.
# So right now, the struct lock * is a speed improvement - we don't have to
# recursivly call down a stack of nodes to be able to lock & unlock a node.
# Chuck's changes would still work - we'd just always recursivly call down.
# Life would just be a bit slower.
# Take care,
# Bill

NetBSD: The devil's advocate.