From owner-freebsd-arch@FreeBSD.ORG Tue Dec 9 01:06:51 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 9A54C106564A; Tue, 9 Dec 2008 01:06:51 +0000 (UTC) (envelope-from marcus@FreeBSD.org) Received: from creme-brulee.marcuscom.com (marcuscom-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::1279]) by mx1.freebsd.org (Postfix) with ESMTP id 5896D8FC16; Tue, 9 Dec 2008 01:06:51 +0000 (UTC) (envelope-from marcus@FreeBSD.org) Received: from [IPv6:2001:470:1f00:2464::4] (shumai.marcuscom.com [IPv6:2001:470:1f00:2464::4]) by creme-brulee.marcuscom.com (8.14.3/8.14.3) with ESMTP id mB918Sxi037921; Mon, 8 Dec 2008 20:08:28 -0500 (EST) (envelope-from marcus@FreeBSD.org) From: Joe Marcus Clarke To: Robert Watson In-Reply-To: References: <1228667168.69753.16.camel@shumai.marcuscom.com> <20081207170354.GI18652@hoeg.nl> <1228670197.69753.24.camel@shumai.marcuscom.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-AiGQsYX7/l7OWYkYDg0Q" Organization: FreeBSD, Inc. Date: Mon, 08 Dec 2008 20:06:45 -0500 Message-Id: <1228784805.69132.66.camel@shumai.marcuscom.com> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 FreeBSD GNOME Team Port X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,MIME_QP_LONG_LINE, NO_RELAYS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on creme-brulee.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: Tue, 09 Dec 2008 01:06:51 -0000 --=-AiGQsYX7/l7OWYkYDg0Q Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2008-12-08 at 18:08 +0000, Robert Watson wrote: > On Sun, 7 Dec 2008, Peter Wemm wrote: >=20 > > Well, you already know I love the idea. Valgrind "knows" that you can=20 > > obtain the pathname from a fd or mmap address reliably at any time beca= use=20 > > of procfs on linux, so its code is structured with that assumption. >=20 > Just to give a general vote of "we need to do something here, whether the= =20 > details are exactly these or not" -- having better object->path resolutio= n is=20 > quite important for audit, as well as if we want to adopt a file system=20 > notification services along the lines of Apple's fsevents (which is=20 > path-centric and operates from close() events rather than open() events).= I=20 > don't think we should run in the Linux 'dentry' direction, but having a m= ore=20 > robust translation service would be quite valuable. One comment: I think= we=20 > should continue to have a KPI which does a sleep-free translation to call= , but=20 > with weaker semantics than one that is sleepable and can query for more r= obust=20 > reverse lookup. Okay, what about a name? vn_fullpath_cache vn_fullpath_quick vn_fullpath_fast vn_fullpath_nosleep ... Joe >=20 > Robert N M Watson > Computer Laboratory > University of Cambridge >=20 > > > > 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. > > > > --=20 > > Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI= 6FJV > > "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" > > >=20 --=20 Joe Marcus Clarke FreeBSD GNOME Team :: gnome@FreeBSD.org FreeNode / #freebsd-gnome http://www.FreeBSD.org/gnome --=-AiGQsYX7/l7OWYkYDg0Q Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAkk9xKQACgkQb2iPiv4Uz4cc6ACdEyt3GfrgbK1WHn9K7XS9WTJS PfwAn2HMmgU9j03VMCQTpq/J1Po7gw/+ =yXBP -----END PGP SIGNATURE----- --=-AiGQsYX7/l7OWYkYDg0Q--