Date: Sun, 07 Dec 2008 14:00:05 -0500 From: Joe Marcus Clarke <marcus@FreeBSD.org> To: Alexander Kabaev <kabaev@gmail.com> Cc: arch@FreeBSD.org Subject: Re: RFC: New VOP to translate vnode to its component name Message-ID: <1228676405.69753.30.camel@shumai.marcuscom.com> In-Reply-To: <20081207114938.44255b35@kan.dnsalias.net> References: <1228667168.69753.16.camel@shumai.marcuscom.com> <20081207114938.44255b35@kan.dnsalias.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--=-5WN0JiyAGvRQA4y7WqGD Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sun, 2008-12-07 at 11:49 -0500, Alexander Kabaev wrote: > On Sun, 07 Dec 2008 11:26:08 -0500 > Joe Marcus Clarke <marcus@FreeBSD.org> 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. VOP_CNP is not a replacement for VFS cache lookups. It tries to supplement the lookup when the lookup fails to find a hit. VOP_CNP itself may not succeed, or may not be appropriate for every file system (its default implementation simply returns ENOENT). However, it does fit well with devfs and pseudofs, and provides accurate enough results in the general cases. Joe --=20 Joe Marcus Clarke FreeBSD GNOME Team :: gnome@FreeBSD.org FreeNode / #freebsd-gnome http://www.FreeBSD.org/gnome --=-5WN0JiyAGvRQA4y7WqGD 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) iEYEABECAAYFAkk8HTQACgkQb2iPiv4Uz4cuigCfeHQYoiYZc92kGBPWCgQGMwHC YKoAni3MDiB1aAebuIc35RPApXxS1jF8 =hTtR -----END PGP SIGNATURE----- --=-5WN0JiyAGvRQA4y7WqGD--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1228676405.69753.30.camel>