Subject: Re: diffs for UVM/UBC improvements available
To: Chuck Silvers <firstname.lastname@example.org>
From: Bill Studenmund <email@example.com>
Date: 05/22/2001 20:32:29
On Tue, 22 May 2001, Chuck Silvers wrote:
> On Tue, May 22, 2001 at 03:00:38PM +0200, Frank van der Linden wrote:
> > On Tue, May 22, 2001 at 02:38:33AM -0700, Chuck Silvers wrote:
> > > - move the vnode lock from struct vnode back into the fs-specific data.
> > > the layered filesystems don't have a separate lock for their vnodes,
> > > so the lock isn't really a vnode property.
> > With that change you have taken a piece of shared code and re-duplicated
> > it into all FS code (except the stacked code). I'm not sure I see the
> > point in this. Also, the idea of having a lock element in the vnode
> > structure was, as I recall (Bill Studenmund did it and will know) to
> > be able to use the same lock for all layers of a layered filesystem.
> > I.e. the upper layers just have pointers to the lower layer's lock.
> > How did you do this now that this no longer exist? Have you tested
> > the known-working layered filesystems (null and layer)?
> I talked with Bill about this a few months back and moving the lock
> back out of the vnode was his idea, actually. the way I've got it here,
> nullfs and friends still use the same lock as the lower filesystem,
> they just get to it via code rather than a pointer.
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.
Yes, I suggested moving the lock out of struct vnode into the fs-specific
code. My reasoning is that layered filesystems will never use the struct
lock in the vnode, so we don't really need to allocate space for it.
> the idea was that since I'm changing struct vnode again now,
> so I might as well make all the changes at once.