Re: RFC: New VOP to translate vnode to its component name
- From: Joe Marcus Clarke <marcus@xxxxxxxxxxx>
- Date: Sun, 07 Dec 2008 14:00:34 -0500
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@xxxxxxxxxxx> wrote:
Background:In general, the relationship between vnode and componentnames is not
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.
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.
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.
Solution:
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).
I would like to commit this work with a possible MFC to RELENG_7 to
come later.
http://www.marcuscom.com/downloads/vop_cnp_10.diff
http://www.marcuscom.com/downloads/VOP_CNP.9
Joe
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.
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.
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
--
Joe Marcus Clarke
FreeBSD GNOME Team :: gnome@xxxxxxxxxxx
FreeNode / #freebsd-gnome
http://www.FreeBSD.org/gnome
Attachment:
signature.asc
Description: This is a digitally signed message part
- References:
- RFC: New VOP to translate vnode to its component name
- From: Joe Marcus Clarke
- Re: RFC: New VOP to translate vnode to its component name
- From: Alexander Kabaev
- Re: RFC: New VOP to translate vnode to its component name
- From: Kostik Belousov
- RFC: New VOP to translate vnode to its component name
- Prev by Date: Re: RFC: New VOP to translate vnode to its component name
- Next by Date: Re: RFC: New VOP to translate vnode to its component name
- Previous by thread: Re: RFC: New VOP to translate vnode to its component name
- Next by thread: Re: RFC: New VOP to translate vnode to its component name
- Index(es):
Relevant Pages
|