From owner-freebsd-arch Thu Sep 12 17:58:24 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DC14837B400 for ; Thu, 12 Sep 2002 17:58:21 -0700 (PDT) Received: from rootlabs.com (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id E933843E4A for ; Thu, 12 Sep 2002 17:58:17 -0700 (PDT) (envelope-from nate@rootlabs.com) Received: (qmail 25432 invoked by uid 1000); 13 Sep 2002 00:58:19 -0000 Date: Thu, 12 Sep 2002 17:58:19 -0700 (PDT) From: Nate Lawson To: Alfred Perlstein Cc: Bruce Evans , phk@FreeBSD.ORG, des@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: PATCH: vnode->v_tag to const char * In-Reply-To: <20020912211025.GJ21806@elvis.mu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 12 Sep 2002, Alfred Perlstein wrote: > * Bruce Evans [020912 03:36] wrote: > > > > > The only other option I considered was checking v_op == nfsv2_vnodeop_p > > > but that has huge problems in that the vops for NFS are only present when > > > NFS is loaded. > > > > > > If you have a better solution, I'm open to it. > > > > I guess the global is the least of evils. > > Wouldn't most of the 'nfs' specific hacks be applicable to other remote > fs's? So then why not just a 'nfslike' flag where it is needed? I tend to agree although this may end up as a big discussion. I already have added VV_UNSAFE which is a propagation of PFS_PROCDEP (i.e. a kernel-mapped filesystem like procfs). I guess some filesystem groups might be: VV_NATIVE - ufs, ffs, mfs (full owner, ugid/flags support) VV_FOREIGN - msdosfs, ntfs, hpfs (don't support full unix semantics) VV_REMOTE - smbfs, nwfs (network-based) VV_KERNEL - procfs, fdescfs, devfs (view into kernel data) VV_WEIRD - unionfs ;-) Anyway, I'm not the right person for this but if perhaps you could come up with a list of the special cases in the VFS code that require certain semantics, we could check for capabilities instead of relying on the fs type. For instance, NFS would do this: getnewvnode("nfs",... VV_REMOTE | VV_NATIVE) And then vm/vm_swap could then just do if ((vp->v_vflag & VV_REMOTE) != 0) ... In looking through the use of v_tag, all people seemed to care about was VV_REMOTE and VV_KERNEL (as defined above) so perhaps that's all we need. -Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message