Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 12 Sep 2002 17:58:19 -0700 (PDT)
From:      Nate Lawson <nate@root.org>
To:        Alfred Perlstein <bright@mu.org>
Cc:        Bruce Evans <bde@zeta.org.au>, phk@FreeBSD.ORG, des@FreeBSD.ORG, arch@FreeBSD.ORG
Subject:   Re: PATCH: vnode->v_tag to const char *
Message-ID:  <Pine.BSF.4.21.0209121745430.25388-100000@root.org>
In-Reply-To: <20020912211025.GJ21806@elvis.mu.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 12 Sep 2002, Alfred Perlstein wrote:
> * Bruce Evans <bde@zeta.org.au> [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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0209121745430.25388-100000>