From owner-freebsd-arch@FreeBSD.ORG Mon Dec 8 18:08:14 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 3A15B1065679; Mon, 8 Dec 2008 18:08:14 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 135338FC1E; Mon, 8 Dec 2008 18:08:14 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTP id AA9B846B9B; Mon, 8 Dec 2008 13:08:13 -0500 (EST) Date: Mon, 8 Dec 2008 18:08:13 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Peter Wemm In-Reply-To: Message-ID: References: <1228667168.69753.16.camel@shumai.marcuscom.com> <20081207170354.GI18652@hoeg.nl> <1228670197.69753.24.camel@shumai.marcuscom.com> User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Ed Schouten , Joe Marcus Clarke , 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: Mon, 08 Dec 2008 18:08:14 -0000 On Sun, 7 Dec 2008, Peter Wemm wrote: > 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. Just to give a general vote of "we need to do something here, whether the details are exactly these or not" -- having better object->path resolution is quite important for audit, as well as if we want to adopt a file system notification services along the lines of Apple's fsevents (which is path-centric and operates from close() events rather than open() events). I don't think we should run in the Linux 'dentry' direction, but having a more robust translation service would be quite valuable. One comment: I think we should continue to have a KPI which does a sleep-free translation to call, but with weaker semantics than one that is sleepable and can query for more robust reverse lookup. Robert N M Watson Computer Laboratory University of Cambridge > > 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 > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" >