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
# 
# 


				--*greywolf;
--
NetBSD: The devil's advocate.