hi bill,

I'll leave the struct lock pointer in for now, but the discussion is
interesting.  how do you propose to use this pointer for anything
when underlying filesystems are not required to supply it? it seems
to me that the relationships between layers cannot be expressed
using just a pointer to a struct lock.  I can believe that we'll
end up with a pointer to stacking info in the vnode, but that info
be more than just a lock.

-Chuck


On Tue, May 29, 2001 at 12:43:48PM -0700, Bill Studenmund wrote:
> On Wed, 23 May 2001, Bill Studenmund wrote:
> 
> > On Tue, 22 May 2001, Chuck Silvers wrote:
> > 
> > > On Tue, May 22, 2001 at 08:32:29PM -0700, Bill Studenmund wrote:
> > > > Hmmm... I should look at the diff. My thought was we'd keep the struct
> > > > vnode *, which would just point into the fs-private data.
> > > 
> > > actually, here's a reason why this isn't preferable:  it means that
> > > a filesystem which does not use a struct lock to implement VOP_LOCK()
> > > would not work with the layered filesystems.  an example of such a
> > > filesystem would be a cluster filesystem which would need to use a
> > > cluster-wide vnode lock.
> > 
> > That was already covered - if the exported struct lock * was NULL, then
> > layer_{,un}lock() called the underlying VOP_LOCK(). This idea already came
> > up so we could support a layered fs over a unionfs system (which has to do
> > its own lock gyrations).
> > 
> > Any other reason?
> 
> More to the point, could you please not remove the struct lock * part? In
> addition to being used as a way of exporting lock information, I was
> planning on using it for some of the other things from John Heidemann's
> disseratation. If you remove it, I'll probably have to re-add it later,
> which seems like a waste.
> 
> And as above, we have clustered file systems covered with the existing
> code.
> 
> Take care,
> 
> Bill