RFC: New VOP to translate vnode to its component name

[Joe Marcus Clarke]

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 at FreeBSD.org> wrote:
> > 
> > > Background:
> > > 
> > > 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
> > > 
> > 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.
> 
> 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 at FreeBSD.org
FreeNode / #freebsd-gnome
http://www.FreeBSD.org/gnome
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20081207/a3a61804/attachment.pgp