From owner-freebsd-arch Thu Sep 12 21:56:48 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 CE2DD37B400; Thu, 12 Sep 2002 21:56:44 -0700 (PDT) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8C23F43E6A; Thu, 12 Sep 2002 21:56:44 -0700 (PDT) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 5A6A8AE1D7; Thu, 12 Sep 2002 21:56:44 -0700 (PDT) Date: Thu, 12 Sep 2002 21:56:44 -0700 From: Alfred Perlstein To: Nate Lawson Cc: Bruce Evans , phk@FreeBSD.ORG, des@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: PATCH: vnode->v_tag to const char * Message-ID: <20020913045644.GM21806@elvis.mu.org> References: <20020912211025.GJ21806@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i 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 * Nate Lawson [020912 17:58] wrote: > On Thu, 12 Sep 2002, Alfred Perlstein wrote: > > > > 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. It seems like you've put quite a bit more thought into this than I have, why not just take a bit of time to see how well your proposal maps to what we have, then do a quick drive-by commit, no one will complain. ;) -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message