Date: Wed, 10 Dec 2008 18:23:12 +0200 From: Kostik Belousov <kostikbel@gmail.com> To: Joe Marcus Clarke <marcus@freebsd.org> Cc: Ed Schouten <ed@80386.nl>, Robert Watson <rwatson@freebsd.org>, arch@freebsd.org Subject: Re: RFC: New VOP to translate vnode to its component name Message-ID: <20081210162312.GO2038@deviant.kiev.zoral.com.ua> In-Reply-To: <1228894344.35477.40.camel@shumai.marcuscom.com> References: <1228667168.69753.16.camel@shumai.marcuscom.com> <20081207170354.GI18652@hoeg.nl> <1228670197.69753.24.camel@shumai.marcuscom.com> <e7db6d980812071143x4d395c7bt3f871e95430efc94@mail.gmail.com> <alpine.BSF.1.10.0812081805120.91087@fledge.watson.org> <1228784805.69132.66.camel@shumai.marcuscom.com> <alpine.BSF.1.10.0812091120380.34663@fledge.watson.org> <1228894344.35477.40.camel@shumai.marcuscom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--3h+hNn3PVp185ISI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Dec 10, 2008 at 02:32:24AM -0500, Joe Marcus Clarke wrote: > On Tue, 2008-12-09 at 11:22 +0000, Robert Watson wrote: > > On Mon, 8 Dec 2008, Joe Marcus Clarke wrote: > >=20 > > >> Just to give a general vote of "we need to do something here, whethe= r the=20 > > >> details are exactly these or not" -- having better object->path reso= lution=20 > > >> is quite important for audit, as well as if we want to adopt a file = system=20 > > >> notification services along the lines of Apple's fsevents (which is= =20 > > >> path-centric and operates from close() events rather than open() eve= nts).=20 > > >> I don't think we should run in the Linux 'dentry' direction, but hav= ing a=20 > > >> more robust translation service would be quite valuable. One commen= t: I=20 > > >> think we should continue to have a KPI which does a sleep-free trans= lation=20 > > >> to call, but with weaker semantics than one that is sleepable and ca= n query=20 > > >> for more robust reverse lookup. > > > > > > Okay, what about a name? > >=20 > > Oh, I do love a good bikeshed. I'm actually fine with any of these, bu= t=20 > > vn_fullpath_cache() sounds good to me. One of the cases I have in mind= is=20 > > path-based MAC policies, which will convert from a vnode to a path whil= e=20 > > holding the vnode lock -- if something is going to run around locking v= nodes=20 > > and doing VOP_READDIR's, that is not the time to do it. >=20 > 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. >=20 > http://www.marcuscom.com/downloads/vop_vptocnp_7.diff Main reason for vn_fullpath_cache() is to not sleep inside the function. I think this shall be reflected in the man page changes you did. I do not like having the old code pasted into the vfs_cache.c together with new implementation. I think that vn_fullpath1 can take a flag specifying whether to call the vop, and return ENOENT when call is disabled. This shall give the same effect without code bloat. --3h+hNn3PVp185ISI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkk/7PAACgkQC3+MBN1Mb4i5VwCguSB+Pak1B26C7oZZv86wlap+ ljYAnAgUky/jvrhfWd42/lIPc2/6SP4l =mFtC -----END PGP SIGNATURE----- --3h+hNn3PVp185ISI--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20081210162312.GO2038>