From owner-freebsd-arch@FreeBSD.ORG Sun Dec 7 18:12:34 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 5735F1065678 for ; Sun, 7 Dec 2008 18:12:34 +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 EBA918FC14 for ; Sun, 7 Dec 2008 18:12:33 +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 1L9NZv-00043d-B4; Sun, 07 Dec 2008 19:37:59 +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 mB7HbttC052077 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 7 Dec 2008 19:37:55 +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 mB7HbtFX016924; Sun, 7 Dec 2008 19:37:55 +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 mB7Hbth7016922; Sun, 7 Dec 2008 19:37:55 +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: Sun, 7 Dec 2008 19:37:55 +0200 From: Kostik Belousov To: Alexander Kabaev Message-ID: <20081207173755.GN2038@deviant.kiev.zoral.com.ua> References: <1228667168.69753.16.camel@shumai.marcuscom.com> <20081207114938.44255b35@kan.dnsalias.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HJakWL7yBo69DI1O" Content-Disposition: inline In-Reply-To: <20081207114938.44255b35@kan.dnsalias.net> 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 1L9NZv-00043d-B4 e1cb16d4ed73cd1b459317f6fef5f136 X-Terabit: YES Cc: arch@freebsd.org, Joe Marcus Clarke 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 18:12:34 -0000 --HJakWL7yBo69DI1O Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Dec 07, 2008 at 11:49:38AM -0500, Alexander Kabaev wrote: > On Sun, 07 Dec 2008 11:26:08 -0500 > Joe Marcus Clarke wrote: >=20 > > Background: > >=20 > > Procstat (i.e. kinfo_file) was a great addition which allows userland > > processes to get a list of open files for a process without the need > > for elevated privileges (e.g. kmem access). This feature uses the > > VFS cache to find component names from vnodes in a process' file > > descriptor table. Because of its ease of use, I quickly deployed it > > into libgtop so that it could provide an lsof-like feature for > > FreeBSD. > >=20 > > Another need arose that seemed perfect for procstat: the ability to > > find out what process had the various mouse devices open. This was > > needed for X.Org's HAL integration. Unfortunately, due to the fact > > that devfs did not make use of the VFS cache, this was impossible to > > do without bringing it a lot of kvm code from fstat, or simply > > exec'ing fstat periodically. I chose the latter. The consequence is > > easier-to-read code, but a performance hit with default HAL > > configurations. > >=20 > > Robert Watson suggested I teach the VFS cache lookup function to query > > file systems directly when cache lookups fail. After a few false > > starts, and with the help of kib, I think I have a committable > > implementation. > >=20 > > Solution: > >=20 > > Here is a patch to HEAD, along with a man page, for VOP_CNP. VOP_CNP > > translates a vnode to its component name. It is currently called from > > vn_fullpath1() to traverse a vnode hierarchy when cache lookups for > > those vnodes fail. I have currently implemented VOP_CNP for devfs and > > pseudofs. Kostik has thoroughly reviewed the devfs implementation. I > > only recently did the pseudofs implementation at his request. > > Additionally, the devfs implementation has gone through a Peter Holm > > stress test, and survives (the pseudofs implementation survives > > WITNESS and VFS lock debugging). > >=20 > > I would like to commit this work with a possible MFC to RELENG_7 to > > come later. > >=20 > > http://www.marcuscom.com/downloads/vop_cnp_10.diff > > http://www.marcuscom.com/downloads/VOP_CNP.9 > >=20 > > Joe > >=20 > In general, the relationship between vnode and componentnames is not > 1:1, so I do not see how this VOP can possibly be made a permanent part > of our VFS interface, as its definition is bogus by design. In what sence its definition is bogus ? The vop should try to give a component name and a parent directory, if possible. It is perfectly acceptable to have several names, and return whatever is considered most suitable. Implementation may choose to always return a third element in some internal list, imagine any weird variant. Devfs implementation falls into this category. Or, it is possible to always return ENOENT, as is done in default implementation. I already discussed a possibility to add helper function that would do the usual readdir("..") to find vnode name for VDIR vnodes, with Peter Wemm. Using it as default implementation of vop_cnp should improve operation of vn_fullpath in general, and esp. on NFS. Personally for me, it would improve the accuracy of still alive patch that adds $ORIGIN support to rtld :). Please, state you objections more explicit. --HJakWL7yBo69DI1O Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkk8CfIACgkQC3+MBN1Mb4iZOACePemsWP3N0kWWwW2cb1/DRrwn 3MAAnj7Ga53vCnDgfJWHGuGNbIPrii/G =Nv3E -----END PGP SIGNATURE----- --HJakWL7yBo69DI1O--