RFC: New VOP to translate vnode to its component name

[Joe Marcus Clarke]

On Tue, 2008-12-09 at 11:22 +0000, Robert Watson wrote:
> On Mon, 8 Dec 2008, Joe Marcus Clarke wrote:
> 
> >> Just to give a general vote of "we need to do something here, whether the 
> >> details are exactly these or not" -- having better object->path resolution 
> >> is quite important for audit, as well as if we want to adopt a file system 
> >> notification services along the lines of Apple's fsevents (which is 
> >> path-centric and operates from close() events rather than open() events). 
> >> I don't think we should run in the Linux 'dentry' direction, but having a 
> >> more robust translation service would be quite valuable.  One comment: I 
> >> think we should continue to have a KPI which does a sleep-free translation 
> >> to call, but with weaker semantics than one that is sleepable and can query 
> >> for more robust reverse lookup.
> >
> > Okay, what about a name?
> 
> Oh, I do love a good bikeshed.  I'm actually fine with any of these, but 
> vn_fullpath_cache() sounds good to me.  One of the cases I have in mind is 
> path-based MAC policies, which will convert from a vnode to a path while 
> holding the vnode lock -- if something is going to run around locking vnodes 
> and doing VOP_READDIR's, that is not the time to do it.

I've duplicated vn_fullpath, vn_fullpath_global, and textvp_fullpath in
this latest version.  The new (well, old) functions are named *_cache.
I even updated the vn_fullpath.9 man page.

http://www.marcuscom.com/downloads/vop_vptocnp_7.diff

Joe

> 
> Robert N M Watson
> Computer Laboratory
> University of Cambridge
> 
> >
> > vn_fullpath_cache
> > vn_fullpath_quick
> > vn_fullpath_fast
> > vn_fullpath_nosleep
> > ...
> >
> > Joe
> >
> >>
> >> Robert N M Watson
> >> Computer Laboratory
> >> University of Cambridge
> >>
> >>>
> >>> Using procfs (on 4.x and 6.x) or the kinfo stuff on 7.x+ sort of
> >>> works, but it quickly becomes unusable if any paths involve NFS.  nfs
> >>> times out its cached items very quickly.
> >>>
> >>> Anyway, I see this as a good first step.  I very much want to see a
> >>> real vop_default implementation that does the readdir("..") method to
> >>> fill in the gaps. It isn't particularly important to me if
> >>> vn_fullpath() recovers the original pathname or not, so long as it can
> >>> find *a* valid pathname that will work.
> >>>
> >>> As for names.. VOP_CNP doesn't tell me what it does at a glance.  Ideas:
> >>> VOP_VPTOCNP  (vnode to component name, or VOP_VNTOCNP)
> >>> VOP_RLOOKUP (reverse lookup)
> >>>
> >>> We have precedent for the first form.  VOP_FHTOVP().
> >>>
> >>> I don't think VOP_VPTOCNP() is too unwieldy and I think it would be a
> >>> little more intuitive to a casual observer.  I don't want to get
> >>> trapped in a bikeshed sized To:/CC: list over it though.  I'd rather
> >>> see it committed to head and get some progress.
> >>>
> >>> BTW: at work we do extensive open-by-filehandle stuff on NFS.  For the
> >>> vast majority of vnodes on those machines, there never was a name
> >>> cache entry.  It would be priceless if the vop_default readdir(..)
> >>> method could discover those names in procstat etc.
> >>>
> >>> --
> >>> 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
> >>> _______________________________________________
> >>> freebsd-arch at freebsd.org mailing list
> >>> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> >>> To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"
> >>>
> >>
> > -- 
> > Joe Marcus Clarke
> > FreeBSD GNOME Team      ::      gnome at FreeBSD.org
> > FreeNode / #freebsd-gnome
> > http://www.FreeBSD.org/gnome
> >
> 
-- 
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/20081210/caa102b4/attachment.pgp