From owner-freebsd-arch@FreeBSD.ORG Sun Dec 7 17:16:35 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 30FF71065670 for ; Sun, 7 Dec 2008 17:16:35 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: from mail-qy0-f18.google.com (mail-qy0-f18.google.com [209.85.221.18]) by mx1.freebsd.org (Postfix) with ESMTP id C14AC8FC1A for ; Sun, 7 Dec 2008 17:16:34 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: by qyk11 with SMTP id 11so942746qyk.19 for ; Sun, 07 Dec 2008 09:16:34 -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=noGznH+fR7mwKeQHsVdg3SShmxJq4lIDDppoKJE/wjY=; b=DmjvC+gx2Da+zrzponVfWhAeNcSbb9EFpv2ynUdhHbMSEydAATYbCz6H1fjMNTbLcG L5X40LpdJ+Ok2kVQi9SsSQIsPw4ga6POHtvQ8hZ4wD5Bb2d/8u8qXVI22zWrf9qJon0Z aeXGZYee3iVmmI9Sk9zCyGTltD013VGUpcRCk= 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=cT9GTDpKeFVmeKbZwAASAnP9vGG1N5E3TuFcuiXbMxuZFJx2hcbdtcl8CdXKvgqrVT O2vsL3SCLPt9gXSMMLYH42Bn0IslAHXALCtNqJZAWHWHIDE+65EtiS8NYyI3rjNvbX69 bWqi2BAGxeJVfh13MrrAEuW5/bie/teKWhkn0= Received: by 10.214.78.17 with SMTP id a17mr1514259qab.141.1228668589272; Sun, 07 Dec 2008 08:49:49 -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 4sm11742287yxj.7.2008.12.07.08.49.42 (version=SSLv3 cipher=RC4-MD5); Sun, 07 Dec 2008 08:49:48 -0800 (PST) Date: Sun, 7 Dec 2008 11:49:38 -0500 From: Alexander Kabaev To: Joe Marcus Clarke Message-ID: <20081207114938.44255b35@kan.dnsalias.net> In-Reply-To: <1228667168.69753.16.camel@shumai.marcuscom.com> References: <1228667168.69753.16.camel@shumai.marcuscom.com> 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_/nSbrU2cOXEbEP1NwvOtBFEZ"; protocol="application/pgp-signature"; micalg=PGP-SHA1 Cc: 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: Sun, 07 Dec 2008 17:16:35 -0000 --Sig_/nSbrU2cOXEbEP1NwvOtBFEZ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Sun, 07 Dec 2008 11:26:08 -0500 Joe Marcus Clarke wrote: > 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 Alexander Kabaev --Sig_/nSbrU2cOXEbEP1NwvOtBFEZ Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iD8DBQFJO/6iQ6z1jMm+XZYRAtRPAKDVS/53jccwtSK6PYQMUANCEj7GKgCfbeax ui97ex4nvVwFwEYEWUdRlTo= =vDa0 -----END PGP SIGNATURE----- --Sig_/nSbrU2cOXEbEP1NwvOtBFEZ--