Date: Sun, 07 Dec 2008 14:00:34 -0500 From: Joe Marcus Clarke <marcus@FreeBSD.org> To: Kostik Belousov <kostikbel@gmail.com> Cc: arch@FreeBSD.org Subject: Re: RFC: New VOP to translate vnode to its component name Message-ID: <1228676434.69753.33.camel@shumai.marcuscom.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
--=-GXVcjYwYt/7649pIKibv Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sun, 2008-12-07 at 19:37 +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 <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 quer= y > > > 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 fro= m > > > vn_fullpath1() to traverse a vnode hierarchy when cache lookups for > > > those vnodes fail. I have currently implemented VOP_CNP for devfs an= d > > > 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. >=20 > 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. As does the pseudofs implementation which handles the case of a directory on a procfs file system specially. Even though the directory has a pn_name of "pid," the VOP_CNP returns the PID as the name instead. > 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. Yes, Peter briefly mentioned this to me as well. Joe --=20 Joe Marcus Clarke FreeBSD GNOME Team :: gnome@FreeBSD.org FreeNode / #freebsd-gnome http://www.FreeBSD.org/gnome --=-GXVcjYwYt/7649pIKibv 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) iEYEABECAAYFAkk8HVEACgkQb2iPiv4Uz4eZZQCgjZ+DK6vEW9ae21uYXPggjbBu jswAoJQs2ZvUvKa14Bq1WxWOf5yOA29j =IPV+ -----END PGP SIGNATURE----- --=-GXVcjYwYt/7649pIKibv--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1228676434.69753.33.camel>