From owner-freebsd-fs  Mon Jul 29 07:02:42 1996
Return-Path: owner-fs
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id HAA27242
          for fs-outgoing; Mon, 29 Jul 1996 07:02:42 -0700 (PDT)
Received: from root.com (implode.root.com [198.145.90.17])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id HAA27237
          for <freebsd-fs@freebsd.org>; Mon, 29 Jul 1996 07:02:39 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.5/8.6.5) with SMTP id GAA26819; Mon, 29 Jul 1996 06:56:28 -0700 (PDT)
Message-Id: <199607291356.GAA26819@root.com>
X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol
To: Doug Rabson <dfr@render.com>
cc: "Martin v.Loewis" <loewis@cs.tu-berlin.de>, freebsd-fs@freebsd.org
Subject: Re: VGET question 
In-reply-to: Your message of "Mon, 29 Jul 1996 11:06:32 BST."
             <Pine.BSI.3.95.960729105835.8355A-100000@minnow.render.com> 
From: David Greenman <dg@root.com>
Reply-To: dg@root.com
Date: Mon, 29 Jul 1996 06:56:28 -0700
Sender: owner-fs@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

>On Sun, 28 Jul 1996, Martin v.Loewis wrote:
>
>> I wonder whether VOP_VGET should return the vnode locked. Most filesystems
>> check their hash lists, and if the vnode is there, they'll perform 
>> vget(vp,1), thus locking the vnode.
>> If they need a new vnode, they get it from getnewvnode, which returns it
>> unlocked. In all cases I've checked, the vnode is then return unlocked to
>> the caller.
>> So what is the proper behaviour, here?
>
>I think that the current intention is that it should be returned locked.
>The vnode from getnewvnode is locked (for UFS) by calling ufs_ihashins().
>
>I believe that it should take a flag argument to specify whether it should
>be returned locked or unlocked.  This would be consistent with vget() and
>might make it possible to clean up the weird locking code in VOP_LOOKUP.

   I agree with what Doug is saying here, but I should point out that making
this kind of change right now might not be a very good idea. It will make us
quite incompatible with filesystem work being done by Kirk McKusick and other
people, not to mention opening the door for a significant number of new bugs
and instability.
   This type of change really needs to be agreed upon be a larger set of
people (outside of the FreeBSD group) before being done.

-DG

David Greenman
Core-team/Principal Architect, The FreeBSD Project