RFC: New VOP to translate vnode to its component name

[Alexander Kabaev]

On Sun, 7 Dec 2008 19:37:55 +0200
Kostik Belousov <kostikbel at gmail.com> 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.
>

Which one from possible multiple names should that be and what makes one
name more equal than others?

> It is perfectly acceptable to have several names, and return whatever
> is considered most suitable.


Decides who? This is _generic_ VFS interface we are speaking about,
not procfs or devfs kludge. VOP_CNP is precisely that - a kludge.

> Implementation may choose to always
> return a third element in some internal list, imagine any weird
> variant. Devfs implementation falls into this category.
> 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.

Then it does belong in vn_fullpatch and not as VNODE operation.
 
> Personally for me, it would improve the accuracy of still alive patch
> that adds $ORIGIN support to rtld :).
> 
> Please, state you objections more explicit.

I believe I did.

-- 
Alexander Kabaev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20081207/77143351/signature.pgp