RFC: New VOP to translate vnode to its component name
kabaev at gmail.com
Sun Dec 7 11:48:32 PST 2008
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
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20081207/77143351/signature.pgp
More information about the freebsd-arch