From owner-freebsd-arch@FreeBSD.ORG Wed Dec 10 16:23:19 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 1662B106567B; Wed, 10 Dec 2008 16:23:19 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.terabit.net.ua (mail.terabit.net.ua [195.137.202.147]) by mx1.freebsd.org (Postfix) with ESMTP id AA1EC8FC13; Wed, 10 Dec 2008 16:23:18 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from skuns.zoral.com.ua ([91.193.166.194] helo=mail.zoral.com.ua) by mail.terabit.net.ua with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1LARqG-000PXl-SE; Wed, 10 Dec 2008 18:23:17 +0200 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id mBAGNDJf052312 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Dec 2008 18:23:13 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id mBAGNDBo018561; Wed, 10 Dec 2008 18:23:13 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id mBAGND3n018559; Wed, 10 Dec 2008 18:23:13 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 10 Dec 2008 18:23:12 +0200 From: Kostik Belousov To: Joe Marcus Clarke Message-ID: <20081210162312.GO2038@deviant.kiev.zoral.com.ua> References: <1228667168.69753.16.camel@shumai.marcuscom.com> <20081207170354.GI18652@hoeg.nl> <1228670197.69753.24.camel@shumai.marcuscom.com> <1228784805.69132.66.camel@shumai.marcuscom.com> <1228894344.35477.40.camel@shumai.marcuscom.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3h+hNn3PVp185ISI" Content-Disposition: inline In-Reply-To: <1228894344.35477.40.camel@shumai.marcuscom.com> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua X-Virus-Scanned: mail.terabit.net.ua 1LARqG-000PXl-SE 851d7fa9d366cdfbcc75c4b78d3352a4 X-Terabit: YES Cc: Ed Schouten , Robert Watson , 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: Wed, 10 Dec 2008 16:23:19 -0000 --3h+hNn3PVp185ISI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Dec 10, 2008 at 02:32:24AM -0500, Joe Marcus Clarke wrote: > On Tue, 2008-12-09 at 11:22 +0000, Robert Watson wrote: > > On Mon, 8 Dec 2008, Joe Marcus Clarke wrote: > >=20 > > >> Just to give a general vote of "we need to do something here, whethe= r the=20 > > >> details are exactly these or not" -- having better object->path reso= lution=20 > > >> is 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() eve= nts).=20 > > >> I don't think we should run in the Linux 'dentry' direction, but hav= ing a=20 > > >> more robust translation service would be quite valuable. One commen= t: I=20 > > >> think we should continue to have a KPI which does a sleep-free trans= lation=20 > > >> to call, but with weaker semantics than one that is sleepable and ca= n query=20 > > >> for more robust reverse lookup. > > > > > > Okay, what about a name? > >=20 > > Oh, I do love a good bikeshed. I'm actually fine with any of these, bu= t=20 > > vn_fullpath_cache() sounds good to me. One of the cases I have in mind= is=20 > > path-based MAC policies, which will convert from a vnode to a path whil= e=20 > > holding the vnode lock -- if something is going to run around locking v= nodes=20 > > and doing VOP_READDIR's, that is not the time to do it. >=20 > I've duplicated vn_fullpath, vn_fullpath_global, and textvp_fullpath in > this latest version. The new (well, old) functions are named *_cache. > I even updated the vn_fullpath.9 man page. >=20 > http://www.marcuscom.com/downloads/vop_vptocnp_7.diff Main reason for vn_fullpath_cache() is to not sleep inside the function. I think this shall be reflected in the man page changes you did. I do not like having the old code pasted into the vfs_cache.c together with new implementation. I think that vn_fullpath1 can take a flag specifying whether to call the vop, and return ENOENT when call is disabled. This shall give the same effect without code bloat. --3h+hNn3PVp185ISI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkk/7PAACgkQC3+MBN1Mb4i5VwCguSB+Pak1B26C7oZZv86wlap+ ljYAnAgUky/jvrhfWd42/lIPc2/6SP4l =mFtC -----END PGP SIGNATURE----- --3h+hNn3PVp185ISI--