On Tue, 13 Mar 2001, Jason R Thorpe wrote:

> On Tue, Mar 13, 2001 at 02:29:05PM -0800, Bill Studenmund wrote:
> 
>  > That actually is the other way to fix the problem, though with doing this
>  > the vput really should be a vrele() (since otherwise you're implicitly
>  > relying on specfs using the nolock routines :-)
> 
> Is there any reason to keep using the "nolock" routines?  Well, a few
> things still use them.  But it seems like you want locking on e.g. spec
> nodes, right?

The only reason I can think of to use the nolock routines is that we
haven't tried/tested using the lock ones.

The big consumer that I was aware of for the nolock routines was nfs. But
in -current, we have fixed the locking bugs. :-)

I don't think the locking really matters on the spec nodes, since we
always unlock and re-lock around calling the read & write
routines. :-) But using the lock routines here would make spec_vnodep_p
consistent with all real fs's. :-)

Hmmm... Thinking about it, one of the things I was thinking about was
moving struct lock back out of struct vnode, into the fs-specific areas.
Mainly since a vnode in a layered fs will (except for unionfs) never use
its own struct lock, we're wasting space. If we do that, then the nolock
routines are right as there is no fs-specific data for specfs vnodes, thus
no struct lock. :-)

Take care,

Bill