RFC: New VOP to translate vnode to its component name

[Peter Wemm]

On Sun, Dec 7, 2008 at 11:48 AM, Alexander Kabaev <kabaev at gmail.com> wrote:
> 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.

vn_fullpath() is already this way.  It is NOT guaranteed to give you
the exact path that was used, but rather *a* working path.  It is
already using the *first* match it finds in the cache.  I see nothing
wrong with a generic VOP that asks "tell me A name and parent
directory".  This is strictly "best effort" only.

If you want to determine the actual path, then you're going to need to
modify the filedesc and vm_map_* structures to cache the actual
pathname used.  Of course, that is useless when you start renaming
parent directory components, or files get moved, or whatever.

Do you have a use in mind that would justify the complexity of
changing the VOP_CNP() from returning a single path/parent to instead
return a list of path/parent pairs?

I don't see this vop needing to spread further than devfs, pseudofs
and a 'readdir("..")' default method.

-- 
Peter Wemm - peter at wemm.org; peter at FreeBSD.org; peter at yahoo-inc.com; KI6FJV
"All of this is for nothing if we don't go to the stars" - JMS/B5
"If Java had true garbage collection, most programs would delete
themselves upon execution." -- Robert Sewell