Date: Tue, 28 Nov 2006 12:27:26 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: Nikolay Pavlov <quetzal@zone3000.net> Cc: freebsd-hackers@freebsd.org Subject: Re: vn_fullpath question. Message-ID: <20061128122407.B27930@fledge.watson.org> In-Reply-To: <20061127120740.GA12728@zone3000.net> References: <20061127120740.GA12728@zone3000.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 27 Nov 2006, Nikolay Pavlov wrote: > Hi. I am trying to extend fstat utility, so that it can use name cache to > recreate full path at least for text. I have found vn_fullpath function > usefull in this case. I am newbe in C, so it could be stupid question, but > could someone explaine what is "struct thread *td" in argument list of this > function. Is this the thread which opened the vnode initially or it is the > thread which searches for the vnode? i.e. fstat thread. In any case how i > can get this *td structure? vn_fullpath(9) is a kernel API, not a user API, so can only be invoked from kernel space. There are unimplemented, undocumented prototypes in the system call table for __getpath_fromfd() and __getpath_fromaddr(), which are presumably intended (with adequate permissions) to allow converting file descriptor indexes into paths, etc. I think Peter dropped them in, but I'm not sure if he's posted patches. It's worth also remembering that paths are slightly confusing things, that really only exist at time-of-lookup. The path to an object may vary by process (due to chroot, etc), for example, or objects may no longer have paths (be unlinked). It's also the case that two objects might have the same "path" due to synthetic objects like /proc/curproc, overlayed mountpoints, etc. vn_fullpath(9) makes a "best effort" based on the contents of the name cache, but can fail to produce meaningful or any results. Robert N M Watson Computer Laboratory University of Cambridge
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061128122407.B27930>