From owner-freebsd-arch@FreeBSD.ORG Sun Dec 7 19:43:02 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A69071065675 for ; Sun, 7 Dec 2008 19:43:02 +0000 (UTC) (envelope-from peter@wemm.org) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.172]) by mx1.freebsd.org (Postfix) with ESMTP id 856498FC28 for ; Sun, 7 Dec 2008 19:43:02 +0000 (UTC) (envelope-from peter@wemm.org) Received: by wf-out-1314.google.com with SMTP id 24so933386wfg.7 for ; Sun, 07 Dec 2008 11:43:02 -0800 (PST) Received: by 10.143.155.7 with SMTP id h7mr1098425wfo.153.1228678982075; Sun, 07 Dec 2008 11:43:02 -0800 (PST) Received: by 10.142.255.21 with HTTP; Sun, 7 Dec 2008 11:43:02 -0800 (PST) Message-ID: Date: Sun, 7 Dec 2008 11:43:02 -0800 From: "Peter Wemm" To: "Joe Marcus Clarke" In-Reply-To: <1228670197.69753.24.camel@shumai.marcuscom.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1228667168.69753.16.camel@shumai.marcuscom.com> <20081207170354.GI18652@hoeg.nl> <1228670197.69753.24.camel@shumai.marcuscom.com> Cc: Ed Schouten , arch@freebsd.org Subject: Re: RFC: New VOP to translate vnode to its component name X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Dec 2008 19:43:02 -0000 On Sun, Dec 7, 2008 at 9:16 AM, Joe Marcus Clarke wrote: > On Sun, 2008-12-07 at 18:03 +0100, Ed Schouten wrote: >> Hello Joe, >> >> * Joe Marcus Clarke wrote: >> > Here is a patch to HEAD, along with a man page, for VOP_CNP. >> >> Maybe this should be called VOP_COMPONENTNAME? I know, it's not as short >> as VOP_CNP, but is probably less cryptic to people who are trying to >> figure out how the VFS works. > > I'm open to a new name, but VOP_COMPONENTNAME does seem a bit unwieldy. > What about VOP_VPTONAME (in the same vein as VOP_VPTOFH)? > > Joe Well, you already know I love the idea. Valgrind "knows" that you can obtain the pathname from a fd or mmap address reliably at any time because of procfs on linux, so its code is structured with that assumption. Using procfs (on 4.x and 6.x) or the kinfo stuff on 7.x+ sort of works, but it quickly becomes unusable if any paths involve NFS. nfs times out its cached items very quickly. Anyway, I see this as a good first step. I very much want to see a real vop_default implementation that does the readdir("..") method to fill in the gaps. It isn't particularly important to me if vn_fullpath() recovers the original pathname or not, so long as it can find *a* valid pathname that will work. As for names.. VOP_CNP doesn't tell me what it does at a glance. Ideas: VOP_VPTOCNP (vnode to component name, or VOP_VNTOCNP) VOP_RLOOKUP (reverse lookup) We have precedent for the first form. VOP_FHTOVP(). I don't think VOP_VPTOCNP() is too unwieldy and I think it would be a little more intuitive to a casual observer. I don't want to get trapped in a bikeshed sized To:/CC: list over it though. I'd rather see it committed to head and get some progress. BTW: at work we do extensive open-by-filehandle stuff on NFS. For the vast majority of vnodes on those machines, there never was a name cache entry. It would be priceless if the vop_default readdir(..) method could discover those names in procstat etc. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV "All of this is for nothing if we don't go to the stars" - JMS/B5 "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell