From owner-freebsd-arch@FreeBSD.ORG Sun Dec 7 19:48:32 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 2FA2B106564A for ; Sun, 7 Dec 2008 19:48:32 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.27]) by mx1.freebsd.org (Postfix) with ESMTP id CF4398FC0C for ; Sun, 7 Dec 2008 19:48:31 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: by qw-out-2122.google.com with SMTP id 9so201196qwb.7 for ; Sun, 07 Dec 2008 11:48:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:in-reply-to:references:x-mailer:mime-version :content-type; bh=1+YhY0bWSqjKk3ddgS1VSBoLMyBuCXu55zvn39qL8S8=; b=igQeA6JdGvZu1hOVs1zgjYqFQIvq1HJbftuG1f3mwx2d7UvkPsuIAyN6i0jIf44S+A xABAo3Wi5Kv7cdzGmSC3dh+W2vZeBJNiHrWoP4ZhbTAxpwbP+Kr5fDqX0NAAXRjJjayM p9r8SVJPKMK0tVt3bwF4lH205cXF5rvJwHPDs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; b=WNHq1X3XOATkCYhb6U3Tn0Urj3jYREGl/jaG33mtrlIcEeYHHz8PydJdcQEWfXDY49 Z9sF+AGq7TyvEmXtsBvC5VZS0ZoDui6Lm0R+E00Tu53WSE4tdY6qVIIdTiwnFIvGohky 2fSaUbNMaTsblyMwsq6JKfRYN89LicafvIOhw= Received: by 10.215.100.13 with SMTP id c13mr1604674qam.353.1228679307879; Sun, 07 Dec 2008 11:48:27 -0800 (PST) Received: from kan.dnsalias.net (c-24-62-106-68.hsd1.ma.comcast.net [24.62.106.68]) by mx.google.com with ESMTPS id 9sm13318442yxs.5.2008.12.07.11.48.26 (version=SSLv3 cipher=RC4-MD5); Sun, 07 Dec 2008 11:48:27 -0800 (PST) Date: Sun, 7 Dec 2008 14:48:22 -0500 From: Alexander Kabaev To: Kostik Belousov Message-ID: <20081207144822.7ff16504@kan.dnsalias.net> In-Reply-To: <20081207173755.GN2038@deviant.kiev.zoral.com.ua> References: <1228667168.69753.16.camel@shumai.marcuscom.com> <20081207114938.44255b35@kan.dnsalias.net> <20081207173755.GN2038@deviant.kiev.zoral.com.ua> X-Mailer: Claws Mail 3.5.0 (GTK+ 2.12.11; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/ay58P7kCqsgiO_6Z18607Qb"; protocol="application/pgp-signature"; micalg=PGP-SHA1 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 19:48:32 -0000 --Sig_/ay58P7kCqsgiO_6Z18607Qb Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Sun, 7 Dec 2008 19:37:55 +0200 Kostik Belousov wrote: > 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. >=20 > In what sence its definition is bogus ? The vop should try to give a > component name and a parent directory, if possible. > Which one from possible multiple names should that be and what makes one name more equal than others? > It is perfectly acceptable to have several names, and return whatever > is considered most suitable. Decides who? This is _generic_ VFS interface we are speaking about, not procfs or devfs kludge. VOP_CNP is precisely that - a kludge. > 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. >=20 > 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. Then it does belong in vn_fullpatch and not as VNODE operation. =20 > Personally for me, it would improve the accuracy of still alive patch > that adds $ORIGIN support to rtld :). >=20 > Please, state you objections more explicit. I believe I did. --=20 Alexander Kabaev --Sig_/ay58P7kCqsgiO_6Z18607Qb Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iD8DBQFJPCiGQ6z1jMm+XZYRAsrAAKCPTJL38Q1OOxpCRcBtqYIFY4WkigCgvZ33 YtUKVPz7EcxjX2cfO+e11eI= =3oqI -----END PGP SIGNATURE----- --Sig_/ay58P7kCqsgiO_6Z18607Qb--