Date: Mon, 28 Oct 2002 15:42:05 -0500 (EST) From: John Baldwin <jhb@FreeBSD.org> To: Terry Lambert <tlambert2@mindspring.com> Cc: Nate Lawson <nate@root.org>, current@FreeBSD.org, Joe Marcus Clarke <marcus@marcuscom.com> Subject: Re: libgtop port and v_tag changes Message-ID: <XFMail.20021028154205.jhb@FreeBSD.org> In-Reply-To: <3DBD9AD8.1CE671F9@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 28-Oct-2002 Terry Lambert wrote: > John Baldwin wrote: >> Yes. This means that you don't need to even look at v_tag to see >> if it is a UFS vnode or not. What does libgtop want with >> device and inode numbers anways? Does it actually do anything >> useful with them or does it just print them somewhere? Is a user >> going to care if the inode number was obtained from the vnode >> or if we groveled in the internals of UFS to find it? > > The user will, if they try to use "find -inum" to identify the > file name associated with it, since the vnode number is useless > for this purpose, and the inode number is not... particularly > if the information is being obtained from a log file. Erm, the v_cachedid is a cache of the inode number we get from VOP_GETATTR(). In the case of ufs it is the inode number. Really though, does anyone that uses 'libgtop' (please, let's get our priorities straight here) actually _use_ this? Sheesh, does anyone actually _use_ libgtop against kernel core dumps? If not then it shouldn't be groveling around in the kernel fondling implementation details. Instead, it should be using stat(2), or at the worst using a sysctl to get xvnode structures. -- John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.20021028154205.jhb>